Guys -

The real problem with viewport is that it is a GLOBAL setting which applies to 
all aspects of your presentation.  What is needed is a way of selectively 
controlling the zoom/pan behavior of individual display blocks.

You may want to have display elements that are locked to screen coordinates for 
providing a standard look-and-feel for your App.  This is why you should not 
allow Contacts (for example) to zoom.  It is intended to be a scrollable list 
of 
items surrounded on three sides by fixed elements.

The reason that contacts cannot be landscape is the fixed elements.  It would 
be 
essentially impossible to use the index on the right if it were squished 
vertically to fit into landscape.  Essentially it would be necessary to use a 
completely different control layout in landscape mode.  This could certainly be 
done (see the Calculator App, for example), but this gives you effectively two 
different Apps.  You have to draw the line somewhere.  What is simplest and 
best 
for the largest number of users.


What is needed here is a way to zoom and pan the scrolling list without 
affecting the fixed elements around the edges.

While we are at it, we also need a way to allow zooming (changing scale) while 
maintaining some constraints on the panning (scrolling left/right and up/down). 
 
Specifically, what we would probably want is to be able to lock the scrolling 
list on the left side of the screen and only allow up/down motion.

Oh, yeah.  We should also throw in the possibility of line-wrap.  Especially if 
you zoom, you should be able to see the entire name of your contact in one of 
the boxes - even if it took several lines of text.

-----

Now for the real killer.

Viewport controls a lot of other things on your page.  

1. If you have a Select element, viewport controls whether selecting the 
element 
auto-zooms to the part of the page with the control.  This can be very 
disconcerting in a carefully designed App, but is kinda needed for rendering a 
web page that was originally intended for a desktop.

2. Text input boxes are another problem.  If you say user-scalable=no then you 
can have the text entry cursor get outside the display.  Bummer.

3. When you close a text entry or select element you remain zoomed to an 
arbitrary spot in the page.  This is hard to fix, even with JavaScript, because 
if you close the select box without changing anything, you do not get an 
onChange event.

You really cannot win.  Each App, and each display element really needs its own 
rules.

-----

There is also a problem that my testers refer to as the app "going flinky".  
Under some circumstances an ordinarily locked page becomes scrollable.  This 
apparently has something to do with the width calculation being off-by-one, or 
something.  A page that should never scroll at all sometimes "comes loose" and 
floats around when you do scrolling gestures.  It always floats back to the 
fixed position - but it should not have come unglued in the first place.  
Sometimes, switching to landscape and back to portrait will cause it - hence 
the 
thought that maybe a rounding error causes it to seem one pixel too wide...

If anybody has a clean explanation or solution to this, I would certainly 
appreciate it.

-----

Rob - you have a really good point about Apps like the GPS.  What is needed is 
a 
good combination of "Standard Display" and "User-Defined" layout.  The ability 
to select DOM elements from a standard page and remap them to a custom layout 
with new positions and sizes would be wonderful.

A framework that supported such an "alternate screen", and a cool drag and drop 
setup for it, would be great.

The beauty of this would be that it would represent almost no impact on the 
existing App itself.  The App would continue to build the display page just as 
it does now.  The framework would simply grab the necessary elements and build 
them into the "real" display page on the fly.

Remember: Since we are talking Web Apps here, we must not forget that any 
user-defined screen must be sticky:  the page can get reloaded at any time and 
the user should be right back where he was without having to rebuild his custom 
layout.

Anybody who wants to take a stab at it will get extra credit.  :)

Brian




________________________________
From: RobG <[email protected]>
To: iPhoneWebDev <[email protected]>
Sent: Sat, October 9, 2010 1:02:57 AM
Subject: Re: HTML5 character encoding etc.



On Oct 9, 11:53 am, Jesse <[email protected]> wrote:
> If you have designed your web-app for the iPhone screen then you may want to
> prevent zooming.

I've already said I can't think of a good reason to do that, but
accept that someone might.

> This is a perfectly valid use of the meta-tags.
> This is especially relevant if you are packaging your webpage into a native
> app container like phonegap.
>
> Rob, Do you expect your contact list on the iPhone to zoom too?

Yes, why not? I wish I could, because sometimes in poor light or for
certain character combinations I find it difficult to read and rather
than get out reading glasses, it would be so nice to just zoom in a
little.

I can zoom e-mail (a non-web page HTML document). Why do you want to
stop me zooming contacts? One thing I like with iPone e-mail is that
when I rotate to landscape, it zooms a little by default. I would love
contacts to do that too.


> Just because it is a webpage, does not mean it is a 'webpage', html is a
> simple way to define the UI for an application as well.

Just because you think it doesn't look as cool when zoomed doesn't
mean I don't want to do it. It's the information that counts. If I'm
prevented from easily accessing information because zooming has been
deliberately disabled, I form a very low opinion of whoever designed
or developed the UI and I will not use it if there is any alternative.

For example, I have a GPS application that crams lots of information
on the screen so most is in a small font and difficult to read quickly
when doing something else (like sailing or bike riding). I'd love to
zoom so that only the speed is displayed and it fills the entire
screen. But I can't. Why not? Will it break the application? Will the
speed be incorrect? Of course not. The designer chose to cram stuff on
the screen and use a small, difficult to read font, then disable
zooming (or not enable it) so I can't read it easily. That's just
plain stupid.

I can use some other application that displays only the speed, but
then I don't get all the goodies I paid for with the GPS application
(like tracks, waypoints, etc.). So for the sake of allowing zooming, a
basic function that comes for free with iPhone, I don't have a
suitable GPS application.

PS. I ended up buying a bespoke GPS device that displays just speed
and records tracks, and leave the iPhone at home.


--
Rob

-- 
You received this message because you are subscribed to the Google Groups 
"iPhoneWebDev" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/iphonewebdev?hl=en.


      

-- 
You received this message because you are subscribed to the Google Groups 
"iPhoneWebDev" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/iphonewebdev?hl=en.

Reply via email to