Same as Lee, the idea of my post wasn't to be rude, but just to tell that what 
could be true and sounds obvious for some projects are NOT for others.
So that saying "don't do this" is bad. "if such cases (and listing them), this 
sounds like the best solution to concider keeping in mind that..." seems better 
to me.

Zooming for accessibility is to enable in settings, then you zoom using double 
taping with 3 fingers and slide. You now have the same ctrl+mouse scroll you 
find on OSX. This is what you use when you have vision issues (because you use 
it everywhere).
Imagine now the poor UX you provide to you visitor that zoomed + zoom in your 
webpage.
Again, think twice, the obvious solutuon is not always the best FOR ALL (but 
might be for some, agree)

Peace :)

Remi Grumeau

On May 25, 2011, at 6:36 PM, QuickConnect <barney....@gmail.com> wrote:

> Remi and Lee A.,
> 
> I think you might want to chill a little.
> 
> Why would someone want a link to the main site?  Because whoever
> created the mobile site messed up and didn't give the user full
> functionality.  Or could it be that they are coming in on a tablet and
> the mobile site is designed for phones?  Both of these are bad design/
> implementation issues.  They should be handled by better design/
> implementation.  Unfortunately most web sites are horribly designed
> from both the user experience standpoint as well as functionality.
> 
> Why zoom?  There are a lot of people out there with compromised
> vision.  Do you want them to not use your site because they can't see
> the text?  They use zoom a lot in their computing.
> 
> Landscape?  It has it's plusses and minuses.  Why not just plan ahead,
> design/create for both and then let the user decide.
> 
> I'm not saying that I'm any better at site design than your normal
> engineer/programmer.  I'm not.  But let's keep the discussion civil
> and our minds open.
> 
> Lee B.
> 
> On May 25, 7:39 am, Remi Grumeau <remi.grum...@gmail.com> wrote:
>> +1
>> There is no 100% cases solution.
>> Otherwise a stupid computer program could do it all by itself.
>> 
>> Examples:>  do not lock mobile visitors into the mobile site
>> 
>> - Explain me what benefit a mobile user could get from a flash-based
>> desktop website link on the mobile one?
>> - Why the hell would he/she needs a link to the desktop version of a
>> wallpaper website when the mobile one where the mobile one gives
>> device screen optimized wallpapers?
>> - I just see no bloody point to get a link to the dekstop flash sound
>> player soundcloud.com when the mobile website is all about HTML5 audio
>> in mp3
>> - Why would i need to access a small fonts sized heavy and long
>> loading time rollover based website when i can get a touchscreen
>> adapted one?
>> 
>> You seem pretty sure you know more than other people here how to
>> optimize web to mobile (and you probably do, who knows?!)
>> So why would i need an access to the desktop website since the mobile
>> web UX you gonna give will be such a delight? :)
>> 
>>> do not disable zooming
>> 
>> Oh yeah, you're right, so cool to use native-like webGUIs like iUI or
>> JQTouch provide. Pressing links and just see the half of the screen
>> sliding.
>> People love to have to choice between a good or a broken experience,
>> instead of having no choice of a good one.
>> That's why WindowsCE & PalmOS5 blows iOS market share: having the most
>> possible choice is totally adapted to "4 seconds to convince"
>> on-the-go mobile users!
>> 
>> Your facts could be right for your projects, needs, problem solving.
>> But others might have some others than yours...
>> 
>> R.
>> 
>> 
>> 
>> On Wed, May 25, 2011 at 14:25, Lee Andron <l...@andron.com> wrote:
>>> Rob, do you really feel that there are rules that apply in every situation?
>>> I can see you feel strongly, but what do you think gives you the right to
>>> impose the things you prefer onto everyone else?
>> 
>>> -Lee
>> 
>>> On Tue, May 24, 2011 at 10:35 PM, RobG <rg...@iinet.net.au> wrote:
>> 
>>>> It seems that every site that ever there was has decided to create a
>>>> "mobile" version of their site so that when I visit with my iPhone, I
>>>> get the mobile version, not the "real" version. While I appreciate
>>>> that developers are trying to improve my experience of their site,
>>>> there are a couple of fundamental design decisions that are completely
>>>> at odds with that goal.
>> 
>>>> Firstly, do not lock mobile visitors into the mobile site. Makers of
>>>> mobile browsers have gone to great lengths to provide features to
>>>> acommodate normal web sites on small screens. Most users of mobile
>>>> devices are quite capable of using those features (tap-zooming and
>>>> panning being the most obvious) to browse "normal" web sites.
>> 
>>>> If there is a need for a small, light-weight version of the site for
>>>> mobile users, by all means make it availble but *please* provide a
>>>> "Full web site here" button. There should also be a button from the
>>>> main site to the light-weight site, as many "desktop" visitors may
>>>> prefer to use the slimed-down interface and simpler functionality
>>>> (i.e. they'd like to escape the often overloaded and crowded interface
>>>> of most web sites when they have a specific function to perform).
>> 
>>>> I believe that sites shouldn't require two different interfaces, but
>>>> I'm very much into efficient functionality and don't care much for the
>>>> overloaded graphics and effects of many current sites.
>> 
>>>> Secondly, do not, under *any* circumstatnces, disable zooming. Sites
>>>> that lock the scale at 1:1 are absolutely detestable. You are saying
>>>> to your visitors "if you can't read this font at this size, FOAD".
>>>> Most mobile sites use the smallest font they think they can get away
>>>> with, so when I'm on a crowded, bumpy train in bad light trying to
>>>> read a web site and I can't zoom in to get bigger text, I just leave.
>>>> And I don't go back unless I really, really must.
>> 
>>>> Lastly, do not prevent landscape mode. That is the last resort for
>>>> attempting to get the font a little bigger and only emphasises an
>>>> ignorance of the needs of mobile users.
>> 
>>>> There is absolutely no practical reason to do any of the above.
>>>> Designers must realise that users will make up their own minds about
>>>> how to use a site, and that they may use it in ways that the designer
>>>> doesn't expect. But when pages are downloaded to a users' browser,
>>>> they become the users' property and they should be able to actually
>>>> *use* the site in the way that suits them best.
>> 
>>>> --
>>>> Rob
>> 
>>>> --
>>>> You received this message because you are subscribed to the Google Groups
>>>> "iPhoneWebDev" group.
>>>> To post to this group, send email to iphonewebdev@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> iphonewebdev+unsubscr...@googlegroups.com.
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/iphonewebdev?hl=en.
>> 
>>> --
>>> -Lee Andron
>>> 617-272-0936
>>> http://www.linkedin.com/in/andron
>> 
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "iPhoneWebDev" group.
>>> To post to this group, send email to iphonewebdev@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> iphonewebdev+unsubscr...@googlegroups.com.
>>> 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 iphonewebdev@googlegroups.com.
> To unsubscribe from this group, send email to 
> iphonewebdev+unsubscr...@googlegroups.com.
> 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 iphonewebdev@googlegroups.com.
To unsubscribe from this group, send email to 
iphonewebdev+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/iphonewebdev?hl=en.

Reply via email to