mccord on iphone

Clayton H Lewis Clayton.Lewis at Colorado.EDU
Wed May 27 18:02:05 UTC 2009


re
we shouldn't feel
restricted to fulfilling some one-to-one contract between the
'desktop' and 'mobile' pages. So, part of the "cutting things out
bodily" problem might be replaced by one of "what sort of content
shall we display, and how shall we mash it up". This would be
supported, I think, by the data feed service and museum APIs that
we've been chitchatting about.


I agree!
it will be great to learn from the museum folks how this can work for  
them to minimize duplicated design and development effort
On May 27, 2009, at 8:02 AM, James William Yoon wrote:

> Clayton,
>
> This is really awesome stuff!
>
> One thing of note is that since the mobile and desktop experiences
> will necessarily be quite different from each other, we shouldn't feel
> restricted to fulfilling some one-to-one contract between the
> 'desktop' and 'mobile' pages. So, part of the "cutting things out
> bodily" problem might be replaced by one of "what sort of content
> shall we display, and how shall we mash it up". This would be
> supported, I think, by the data feed service and museum APIs that
> we've been chitchatting about.
>
> Let's get together with Tona and review what the McCord would like to
> see in this mobile app, brainstorm some ideas, and start sketching
> some stuff out.
>
> James
>
> On Mon, May 25, 2009 at 10:29 PM, Clayton H Lewis
> <Clayton.Lewis at colorado.edu> wrote:
>> James, I'm in transit Tuesday... here is where I've gotten to w  
>> looking at
>> the McCord search facility on iPhone.
>> There is a semi-working mockup at
>> http://spot.colorado.edu/~clayton/fluid%20stuff/mccordhackip.html.
>> Most of the links go on to the real McCord pages, but the  
>> Paintings, Prints
>> and Drawings link goes on to the next page of the mockup.
>> If you do an actual search you'll go on to real McCord stuff, but  
>> there is a
>> link at the bottom of the search page that goes to a simple mockup  
>> of search
>> results.
>> Points of interest:
>> There is a good deal of stuff on preparing Web content for the  
>> iPhone at
>> http://developer.apple.com/safari/library/documentation/ 
>> AppleApplications/Reference/SafariWebContent/Introduction/ 
>> chapter_1_section_1.html#//apple_ref/doc/uid/TP40002079-SW1.
>> Most of this is general advice, but there is also some iPhone- 
>> specific
>> markup, notably some meta tags (see below).
>> The pages set up for iPhone will render fine (if blandly) on other
>> platforms... BUT, as can be seen, these pages are very different  
>> from the
>> real McCord pages, which are hugely more complex (dozens of links  
>> per page,
>> Flash for viewing images, etc etc etc.)
>> I had to strip out LOTS of stuff to get something reasonable for  
>> the small
>> screen (and of course may not have made the best choices in doing  
>> this.)
>> If museums are to avoid duplicating all their work creating  
>> versions of
>> pages for different platforms, we should develop some way to mark  
>> up what
>> content is crucial and what is peripheral, so one can render just the
>> crucial stuff when needed (with some way to get to the extra  
>> stuff, mapped
>> onto other screens). This would no doubt not be easy to make work,  
>> but would
>> be very valuable, eg for people who don't read well. One  
>> potentially tricky
>> bit: getting from the real McCord pages to the iPhone versions  
>> involved more
>> than just cutting things out bodily; there are things like columns  
>> in tables
>> that should be suppressed for the basic view, where the columns  
>> weren't
>> explicitly tagged. Tagging would need to be more thorough. Maybe a  
>> content
>> management system could semi-automatically incorporate the  
>> "centrality" tags
>> in such a way that less central info could be styled out.
>> There are some iPhone specific things to do, notably the meta tag  
>> that sets
>> the "viewport". I had to fiddle with this (and with the table  
>> layout) to get
>> things to show up at reasonable sizes. I'm far from confident that  
>> I've done
>> this the best way, though the effect seems ok.
>> I also added a meta tag that lets a page be seen "full screen",  
>> like an
>> iPhone app (no "browser chrome"). But this is quite limited: (a)  
>> you ONLY
>> get the effect when you add a bookmark to the page to your home  
>> screen, and
>> get to it from there, not when you access it any other way : ( ,  
>> and, as a
>> result,  (b) the full screen effect is lost when you link to any  
>> other page,
>> even if that page has the right meta tag. Anyway, this is  
>> someone's effort
>> to supply something someone asked about in one of the calls, that  
>> is, to
>> make something on the Web look like a native app.
>> There is an iPhone feature that I hadn't known about that works  
>> nicely if
>> the pages are laid out appropriately, and if the user knows about  
>> it. On the
>> search results page, if you "double tap" on an image, the browser  
>> will
>> automatically pan and zoom to give you the best view of the image.  
>> Similarly
>> for the text items. As mentioned above, it took some fiddling to  
>> get the
>> page laid out so as to have this work. In favorable cases this is  
>> a lot
>> better than "manually" panning and zooming, especially to read  
>> text, for
>> which line lengths are often awkward.
>> On the search page you will see that the select widget renders as  
>> a fancy
>> (?) iPhone spinner. To my eye, this doesn't work very well when  
>> (as in the
>> example) there are multiple selects on the page, in which case (as  
>> you'll
>> see) you get some extra buttons to navigate among the select widgets.
>> (Again, you get this effect from perfectly ordinary HTML that  
>> works as usual
>> on other platforms.) Note that you only see the spinner when you  
>> select one
>> of the select boxes.
>> Flash isn't supported on iPhone (yet? will it be?). So the image  
>> viewer the
>> McCord uses would have to be reworked for this platform.
>> Cheers, Clayton
>>
>>
>> Clayton Lewis
>> Professor of Computer Science
>> Scientist in Residence, Coleman Institute for Cognitive Disabilities
>> University of Colorado
>> http://www.cs.colorado.edu/~clayton
>>
>>
>>
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work

Clayton Lewis
Professor of Computer Science
Scientist in Residence, Coleman Institute for Cognitive Disabilities
University of Colorado
http://www.cs.colorado.edu/~clayton



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20090527/1c9b9ff8/attachment.html>


More information about the fluid-work mailing list