many thanks Trygve

--- In mobile-web@yahoogroups.com, Trygve Lie <post@...> wrote:
>
>
> > reading experience on the iPad.
>
> If your looking for readability and UX for "the iPad" I find Bibliotype
> a good starting point. Its optimized for reading pleasure.
> Site: http://craigmod.com/bibliotype/
> Demo: http://craigmod.com/bibliotype/demo/
>
>
>
> > I mean a mobile Safari website of course
>
> There are more mobile platforms and mobile browsers than just Safari.
> Don't go in the trap of just targeting Safari and the iDevices...
>
> Trygve
>

Hi Martin

I built the pre-login mobi site for a bank in South Africa and we have been
using 'GAM' very successfully for a while now. The results are more than
adequate (especially when you hook it into the rest of the Google suite of
tools).

We stayed away from using the JavaScript version due to the potential problem of
slowing down a site that already has to deal with less than optimal bandwidth as
well as devices that may struggle with the extra load.

Hope this helps

I've started working on the resize event on mobiles and tablets, and
oh my God it's a mess.

What I'd like to know now is when you would expect the resize event to
fire. So far I have identified five occasions:

- onorientationchange
- when the user zooms
- when the content of the <meta viewport> changes
- when content is added to the page, so that the page becomes longer
- when wide content is added to the page, so that the page becomes wider

At least one browser fires the event for all of these five.

Can you think of more actions that would cause a resize event?

--
--------------------------------------------
ppk, mobile platform strategist
http://quirksmode.org/about/
+.31.6.29585782
--------------------------------------------

I would expect a resize event when the browser window are resized.

I suspect that some mobile phones does resize the window when a on
screen keyboard occur on the screen.

Example: on the Samsung SII it looks like the on screen keyboard - which
occupy a part of the screen when one type a URL - affect the initial
screen values.

If one open a fresh new and blank window in WebKit on the SII and enters
a URL an then press enter to load it, window.outerHeight, .clientHeight
etc on the loaded page will return a value MINUS the height of the on
screen keyboard. It seems like the browser window are resized to the
screen size minus the keyboard size, but when the keyboard disappear the
values for the window are not re-adjusted to a screen size without the
keyboard.

If we hit reload (which does not involve showing the on screen keyboard)
on the page we wrote the URL to, values for
window.outerHeight, .clientHeight etc changes to values matching the
screen.

Very annoying thing and I've also heard about a similar problem on some
LG phones. I've not checked if any resize event are fired when this
happen.

Iow; if its the case that some phones does resize the browser window
when a on screen keyboards appear, I would expect a resize event when
that happens.

Kind regards
Trygve



On Wed, 2011-12-07 at 16:57 +0100, Peter-Paul Koch wrote:
> I've started working on the resize event on mobiles and tablets, and
> oh my God it's a mess.
>
> What I'd like to know now is when you would expect the resize event to
> fire. So far I have identified five occasions:
>
> - onorientationchange
> - when the user zooms
> - when the content of the <meta viewport> changes
> - when content is added to the page, so that the page becomes longer
> - when wide content is added to the page, so that the page becomes wider
>
> At least one browser fires the event for all of these five.
>
> Can you think of more actions that would cause a resize event?
>

Hey PPK,

First off I just want to make sure we're all talking about the same things:
http://www.quirksmode.org/mobile/viewports2.html

FYI I'm interpreting viewports a little differently than you do.

Visual Viewport
The actual viewable area (ie: webview component) as determined by the physical
screen size minus browser chrome, etc. I often refer to this as the 'key hole'.

Layout Viewport
The representation of the entire 'page' as determined by the browser. On this
iPhone this is often set to 960px wide for devices that don't specify a meta
width value. I often think of this as the 'page behind the key hole'.

> What I'd like to know now is when you would expect the resize event to
> fire. So far I have identified five occasions:
>
> - onorientationchange

Yes.
If physical width changes from 320 to 480, etc that is a resize of the (visual)
viewport, although often the layout viewport is simply scaled accordingly to fit
the new screen dimensions.

> - when the user zooms

No.
Zooming is simply a scaling of the layout viewport (page) within the visual
viewport (screen hardware).

> - when the content of the <meta viewport> changes

Yes.
This directly impacts the layout viewport and a resize event should be triggered
in order to communicate the change in size. The best example of this type of
behaviour (whether we like it or not) is probably the Zoom Level setting (in
Settings) on Android. The choice of Far, Medium or Close (Kindle Fire also
provides a Huge setting) changes the layout viewport. This in many cases
triggers media queries appropriate to the new layout viewport size, thereby
demonstrating that the viewport has indeed changed size.

> - when content is added to the page, so that the page becomes longer

Yes.
Adding content to the page (layout viewport) should result in a resize event
being fired.

> - when wide content is added to the page, so that the page becomes wider

Yes (same as above).

> At least one browser fires the event for all of these five.

Yup… :(

> Can you think of more actions that would cause a resize event?

No, I think that actually covers it very well IMHO.

Cheers,

Bryan

Slight correction (this is hurting my head):

"Layout Viewport
The representation of the entire 'page' as determined by the browser. On this
iPhone this is often set to 960px wide for devices that don't specify a meta
width value. I often think of this as the 'page behind the key hole'."

Should be:

Layout Viewport
The representation of the entire 'page' as determined by the browser. On this
iPhone this is often set to 960px wide for PAGES that don't specify a meta width
value. I often think of this as the 'page behind the key hole'.

Regards,

Bryan Rieger
Designer, Yiibu


On 7 Dec 2011, at 15:57, Peter-Paul Koch wrote:

> I've started working on the resize event on mobiles and tablets, and
> oh my God it's a mess.
>
> What I'd like to know now is when you would expect the resize event to
> fire. So far I have identified five occasions:
>
> - onorientationchange
> - when the user zooms
> - when the content of the <meta viewport> changes
> - when content is added to the page, so that the page becomes longer
> - when wide content is added to the page, so that the page becomes wider
>
> At least one browser fires the event for all of these five.
>
> Can you think of more actions that would cause a resize event?
>
> --
> --------------------------------------------
> ppk, mobile platform strategist
> http://quirksmode.org/about/
> +.31.6.29585782
> --------------------------------------------
>

On 7 Dec 2011, at 17:56, James Pearce wrote:

> Some edge cases you might also explore:
>
>
>  - CSS zoom, transforms, font-sizes etc that change the size of elements such
that they expand the page

I think this may fall into 'content added to the page' bucket, but along with
Joe's recommendation for "A drag event on an element that is taken outside the
bounds of the current viewport such that it is wider?" …essentially it's changes
in the DOM either through modification of existing content or the
addition/removal of content that would cause a reflow and potentially fire a
resize event if warranted.

>  - changing browser settings while on a page (e.g. those browsers that have
viewport behavior as a setting)

Hmm, this kinda speaks to 'when the user zooms' and 'when the meta viewport'
value changes, but I'm not entirely sure that it doesn't present another edge
case.
More exploration required.

>  - keyboard appearance & disappearance

Ah, excellent addition!
Does the keyboard impact the layout or visual viewport, or is it simply an
overlay?

>  - input type widgets (datetime etc) appearance & disappearance

This follows on and related to the appearance / disappearance of the keyboard
above.
Essentially, any native UI widget/control that is added/remove to the screen.

Thanks James!

.b

Hi, Guys!

Running out the door to something but was reminded that...

We definitely saw some Android browsers firing resize if, while scrolling, the
browser chrome  was revealed. That is, browser chrome starts as invisible off
the top of the viewport; user scrolls; chrome shows up; resize fires. Similar to
the keyboard-showing-up mentioned by James, yeah.

--Lyza

--- In mobile-web@yahoogroups.com, James Pearce <jamesgpearce@...> wrote:
>
> Some edge cases you might also explore:
>
>  - CSS zoom, transforms, font-sizes etc that change the size of elements
> such that they expand the page
>  - changing browser settings while on a page (e.g. those browsers that have
> viewport behavior as a setting)
>  - keyboard appearance & disappearance
>  - input type widgets (datetime etc) appearance & disappearance
>
> JP
>
> On 7 December 2011 07:57, Peter-Paul Koch <pp.koch@...> wrote:
>
> > **
> >
> >
> > I've started working on the resize event on mobiles and tablets, and
> > oh my God it's a mess.
> >
> > What I'd like to know now is when you would expect the resize event to
> > fire. So far I have identified five occasions:
> >
> > - onorientationchange
> > - when the user zooms
> > - when the content of the <meta viewport> changes
> > - when content is added to the page, so that the page becomes longer
> > - when wide content is added to the page, so that the page becomes wider
> >
> > At least one browser fires the event for all of these five.
> >
> > Can you think of more actions that would cause a resize event?
> >
> > --
> > --------------------------------------------
> > ppk, mobile platform strategist
> > http://quirksmode.org/about/
> > +.31.6.29585782
> > --------------------------------------------
> >
> >
>

Thanks, all, for your suggestions. The following was added to my list:

- Drag-and-drop an element to outside the viewport
- The keyboard pops up.
- The date picker pops up
- Changing the browser’s zoom level in the settings
- window.scrollTo(0,1) because it removes the browser chrome in some browsers.
- Scrolling down so far that the browser chrome is revealed.

> FYI I'm interpreting viewports a little differently than you do.
>
> Visual Viewport
> The actual viewable area (ie: webview component) as determined by the physical
screen size minus browser chrome, etc. I often refer to this as the 'key hole'.
>
> Layout Viewport
> The representation of the entire 'page' as determined by the browser. On this
iPhone this is often set to 960px wide for pages that don't specify a meta width
value. I often think of this as the 'page behind the key hole'.

Yes, that's slightly different form my definition.

I *think* the difference is due to what we consider "true" pixels. You
seem to calculate everything from device pixels, while I use CSS
pixels as my frame of reference. In my opinion web developers don't
need to know or care about device pixels, but should take CSS pixels
as leading. We don't care how many hardware pixels there are on the
device, we care how many CSS pixels the user is seeing or should see.

This could become a nice theoretical discussion that explodes heads
all around the Web.


--
--------------------------------------------
ppk, mobile platform strategist
http://quirksmode.org/about/
+.31.6.29585782
--------------------------------------------

CrowdFinch is a leading professional Web Development and Internet Marketing
company offering services like Web Design, Web Application Development, Mobile
Application Development and Web Marketing Solutions. We provide an innovative
solutions with multilevel testing  that fulfill our clients.

More services visit our business website - http://www.crowdfinch.com

Looking for SEX partner! Check my H.O.T photos here:
http://kassonnccs.webs.com/intimate.htm

OK, my research is done and the results are at
http://quirksmode.org/dom/events/resize_mobile.html

Summary:

- When the layout viewport changes, all browsers that are able to
change it fire a resize event.
- When the HTML element changes, half of the browsers fire a resize event.
- When the visual viewport changes, browsers run around like headless
chicken and do whatever they please.

Note: I retained my own definitions of the viewports. I'll discuss
Bryan's suggestions another time; changing your definitions in
mid-test is generally a bad idea.

Discuss.


--------------------------------------------
ppk, mobile platform strategist
http://quirksmode.org/about/
+.31.6.29585782
--------------------------------------------

I'm currently exploring simple device detection options using user agent
matching and would appreciate some advice and pearls of wisdom learned from
experience. I am working on a project to develop a separate mobile experience
for a site that has a pre-existing desktop version.

The most common approach seems to be to test for mobile devices and redirect to
a mobile-specific domain (e.g.
http://mobiforge.com/developing/story/lightweight-device-detection-php and
http://detectmobilebrowsers.com/). The regex involved is fairly verbose, and
likely to need fairly frequent updates.

However, I would like to know what experiences people have had using the reverse
approach, whereby desktop browsers are detected instead. I have found two
examples of this:

- 'Not-device detection':
http://smartmobtoolkit.wordpress.com/2009/01/25/not-device-detection-example-cod\
e/

- 'Not Not Mobile': http://notnotmobile.appspot.com/

It seems to me that if you are delivering a single mobile experience (i.e.
low-end devices or feature phones get the same content as smartphones) that this
approach makes sense, given the complexity of the regex involved and the
relative infrequency of updates that are likely to be needed.

Does anyone have any experiences or thoughts to share of implementing this form
of device detection?

Hi James,

We do something kind of similar, which involves detection of mobile and desktop
browsers based at different layers.

Similarly to you, there was a pre-existing and very 'mature' website built for
desktop browsers with a big ol' clunky CMS behind the scenes, making any sort
ground-up mobile-first type implementation totally off the table.

By adding server side device device detection, we now support smartphone and
feature phone devices independently (separate mobile sites, HTML5 and XHTML
MP1.2 respectively). This happens a fairly stock WURFL implementation.

The part you might be interested in, is the pre-filtering of desktop browsers
that also occurs. For performance reasons, we didn't want every single
web-request piping through WURFL-based device categorisation. So, right up front
there is a very simple regex algorithm which detects desktop browsers. IF true,
bypass mobile device categorisation (and redirection) and go straight to
desktop. IF false, carry on to device detection.

This has worked really well for us. Although I'm not sure I can recommend the
desktop detection stand alone. We have the safety net of "undetected" desktop
browsers being sorted out via WURFL if they're not picked up in the first pass
of detection. If that wasn't there, I suspect things would be a lot messier, and
we'd probably be tweaking our algorithm all the time.

Hope that helps.




--- In mobile-web@yahoogroups.com, "jamesnewbery" <james.newbery@...> wrote:
>
> I'm currently exploring simple device detection options using user agent
matching and would appreciate some advice and pearls of wisdom learned from
experience. I am working on a project to develop a separate mobile experience
for a site that has a pre-existing desktop version.
>
> The most common approach seems to be to test for mobile devices and redirect
to a mobile-specific domain (e.g.
http://mobiforge.com/developing/story/lightweight-device-detection-php and
http://detectmobilebrowsers.com/). The regex involved is fairly verbose, and
likely to need fairly frequent updates.
>
> However, I would like to know what experiences people have had using the
reverse approach, whereby desktop browsers are detected instead. I have found
two examples of this:
>
> - 'Not-device detection':
http://smartmobtoolkit.wordpress.com/2009/01/25/not-device-detection-example-cod\
e/
>
> - 'Not Not Mobile': http://notnotmobile.appspot.com/
>
> It seems to me that if you are delivering a single mobile experience (i.e.
low-end devices or feature phones get the same content as smartphones) that this
approach makes sense, given the complexity of the regex involved and the
relative infrequency of updates that are likely to be needed.
>
> Does anyone have any experiences or thoughts to share of implementing this
form of device detection?
>

Hi,

I got to know of an exciting event happening in Bangalore on Jan 21st.

I guess Mobile World India 2012 comes with the exciting keynote sessions on `How
Operators will meet the Future Traffic Demand', `What Makes a mobile application
successful' and `The Future of Mobile Technology .

I believe it is worth attending as there are interesting topics. (See
the Sessions below).

When: January 21, 2012 (Saturday)
Where: NIMHANS Convention Centre, Hosur Road, Near Diary Circle, Bangalore.
Time: 8.30AM to 5.50PM

The Conference organizers will call you back to confirm. When I called, they had
300 more seats left.

Please find below is the url to go through the website

http://tinyurl.com/mobilewb


Thanks,
William. M

Sessions on:
Digital Marketing: Innovative strategy ,
Social Media Marketing Strategy,
Strategic Marketing - The Need of the Hour,
Mobile Marketing: True Mobile Strategy,
Role of marketing mix in digital era,
Effective Mobile Marketing: Reach to mass community.

You've got a private message! Check it here:
http://file1.hpage.com/007409/48/html/hottie.htm

Like most that are relatively new to mobile web development, I currently use
emulators and simulators for most of my testing, which is not ideal. I would
love to start obtaining some cheap, second-hand devices which cover common
platforms, input mechanisms, etc.

As I am an independent developer, my budget will not run to a Yiibu-esque
library of devices just yet
(http://bagcheck.com/bag/7264-yiibu-s-tools-of-the-trade). However, I need to
start somewhere, and would appreciate any suggestions for possible devices, tips
for getting hold of good deals, and any other worthy advice.

Most of my clients are UK-based, but I am currently working on a long-term
project that is targeted solely to US consumers.

If there are enough replies, I hope to write up the responses in some form, as
there is not a great deal of advice or info out there just now.

Jim

tinnedfruit.com

 

Hi Jim,

Before Brad 'beat me to it' (<330.gif>) with some great phones to look at getting for testing I was going to suggest having a look at Stephanie Riegers' latest blogpost - http://stephanierieger.com/a-plea-for-progressive-enhancement/ where she has listed some devices that she used.

Best 

Stu