mccord on iphone

James William Yoon james.yoon at utoronto.ca
Wed May 27 14:02:04 UTC 2009


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
>
>
>



More information about the fluid-work mailing list