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
<[email protected]> 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 - [email protected]
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
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
