Loading ...
Sorry, an error occurred while loading the content.
 

Re: [wmlprogramming] Re: No need for BP, there is GAP now

Expand Messages
  • Luca Passani
    Thanks Marten. A lot of good points. As far as adaptation being required is concerned, I know exactly what you mean. In fact there were too things that made me
    Message 1 of 32 , Oct 1, 2006
      Thanks Marten. A lot of good points. As far as adaptation being required
      is concerned, I know exactly what you mean. In fact there were too
      things that made me stop contributing to BP: one was one-web and the
      other one was the group's refusal to mandate adaptation,implying that it
      should be possible to have BP-compliant (AKA mobileOK) pages with static
      XHTML pages.
      One-web I ditched, but if I had also completely ditched the second
      requirement, than I would have created something different and left
      space for claims that BPWG had a unique value. This was unacceptable,
      because much better guideliness than BP can be created.
      Getting to your specific points:

      Marten van Wezel wrote:

      >>We all agree about this, but you see, one of the main points of GAP is
      >>that, no matter how much you push people to do adaptation, someone will
      >>do LCD anyway. GAP tells you what the best solution is with LCD and
      >>makes you smell the coffee about how much better you could do with
      >>adaptation. Of course, WURFL users don't need to be told this anyway,
      >>but new comers to mobile development may.
      >>
      >>
      >
      >True enough, but at a certain point you will have removed so much stuff ('because it's too complex') that noone will actually use the practices described. :)
      >
      >
      I disagree. I think that GAP does push to adaptation strongly enough. If
      a developer does not switch to adaptation, at least they know what is
      coming.
      Maybe we should have a new practice that says look at your logs
      periodically and learn about your users. Do you guys look at your logs?
      what kind of information do you extract for them?

      >I don't know if this specific example qualifies, but my main point is this: Assume you run 'radbooks.com'.
      >
      >- A customer will NEVER go from the PC website to the mobile website. The PC website shows a site better, so if you're behind your PC and you've found radbooks.com, and it says 'our mobile site: wap.radbooks.com', do you think the user will turn off their PC? no.
      >
      >
      of course, I agree.

      >- A customer who is on the street, perhaps walks by your storefront. IF you mention your web url on your storefront, you probably won't mention TWO urls. Probably not even one, and you just hope people will try 'radbooks.com' and hey presto.
      >
      >
      hold on a sec. What prevents an ad from reading "Go to
      http://wap.radbooks.com NOW with your mobile phone and win the complete
      Desperate Housewife DVD collection"?
      of course it could be mobile.radbooks.com or radbooks.mobi, but the
      point remains

      >- In general, It would surprise me if -any- user would -ever- try 'mobile.radbooks.com' from their mobile. (until perhaps the day that the 'mobile' prefix is as pervasive in our society as the insipid 'www.' is now. (talk about redundancy, why does everything have to be 'www.', Im wearing out my keyboard here.
      >
      >
      this is what the .mobi guys are trying to do, I believe (too bad they
      endorsed BP. They should do the switch and go GAP).

      >- Lastly, 'wap.' would add another 4 characters to what the user will have to type on a 0-9 keypad to get somewhere.
      >
      >Bottomline, yes newbie developers (addendum: that ARE making an effort
      >to actually build a mobile website) will sometimes be inexperienced and want to do the quickest and easiest way, but at a certain point the easiest way will just not make any business sense at all. This applies to this discussion I feel, so I personally still think you should include for example Jason's quick site switcher.
      >
      >
      Let's go for it. Let's create an entry in WirelessFaq with the switcher.
      Let's improve on it. Let's provide code in PHP, Java and possibly others.

      >
      >Agreed, not that I care for football but yeah, in that formatting thing
      >a table would help. Ive personally historically stayed away from them
      >for the 'LCD' reason.
      >
      >
      The baseline idea is our friend here. By making sure that tables are
      part of the baseline, we can get away from the problem without adaptation

      >
      >>> Additionally I would suggest you add a reference to session
      >>> management, where you link a username, password to a MD5 session
      >>> variable. That way, the user logs in once, and gets pointed to a page
      >>> that says 'you are now logged in. It is advised you BOOKMARK THE NEXT
      >>> PAGE. (where the next page would be
      >>> site.com/index.php?sid=839487987a98f798qhf98adsh)
      >>>
      >>>
      >>>
      >>>
      >>This looks like a great entry for the WirelessFaq which I would gladly
      >>point to from the GAP!
      >>
      >>
      >
      >Fine with me!
      >
      >
      Can you write it?

      >
      >
      >>>- Pagers. I find that users always want to know 'where they are at'.
      >>> This means that if you have want to show them (the choice of) more
      >>> content than can fit on one page, they should not only see a pager
      >>> ('next page/prev') but also one that shows them 'page 1 out of 20'
      >>>
      >>>
      >>>
      >>mmm...I don't like this. For a GAP baseline device this information
      >>would clutter the interface.
      >>On a device with a larger screen, it may make sense. This makes your
      >>suggestion a candidate for adaptation but not LCD. I think this is
      >>covered already here to some extent:
      >>
      >>http://www.passani.it/gap/#NO_TOP_BAR
      >>
      >>
      >
      >Well, no let me clarify a touch.
      >
      >IF you need a pager (i.e. you want the user to choose from 20
      >wallpapers), THEN you will need a 'next, prev page' setup anyway, and IF
      >you have that, I would strongly advise to reccommend adding a 3/20
      >counter to it.
      >
      >This forces the developer to reconsider if ANY user will EVER click on
      >to page 20, as well as perhaps allows the user to consider if he will
      >have the time to read all 20 pages.
      >
      >
      this is a good point. I would say that in this case the difference is
      that the pager *is* the page, and not just a standard addition to the
      page which would clutter the interface. I am clarifying like this:

      Note 2: This practice should not be confused with the case
      where a navigation bar supports a page function. A user may be
      looping through large amounts of text or a list of previews of
      downloadable content. In those case, backward/forward navigation
      as well as knowing how many extra pages are there before the end,
      would not be cluttering the UI, rather they would represent the UI itself.

      >
      >>>- If feedback mail links are part of your business model (i.e. you
      >>> *gasp* care for what your users think), then it is often a good idea
      >>> to add subject and body code that is relevant to the coder. One of the
      >>> most frustrating experiences as a 'helpdesk' for my own site was not
      >>> knowing what page was giving the user trouble. 'Yeah, the page with
      >>> the doohicky and then some OK thingy' is tough to decode, a <a
      >>> href=\"mailto:helpdesk@...?subject=UpdatePassword.php&Body=".urlencode($userid.$nickname.$useragent)."..>mail
      >>> helpdesk</a> might not always actually add those headers (with crappy
      >>> mailclients) but if it does, they are a godsend.
      >>>
      >>>
      >>>
      >>>
      >>the problem is that I cannot assume baseline device has an email client
      >>and that it's correctly configured.
      >>
      >>
      >
      >The way I personally handled that is indeed an 'emaillinkgenerator'
      >which either points to a mailto: link OR a form. But yeah I suppose it
      >is too tough as a baseline, although it might make a good
      >reccommendation.
      >
      >
      still seems to invade the business model of the application a bit too
      much. Also, I don't think that many people will spend time to report in
      writing what was wrong from a mobile device. Maybe a set of 5 links to
      report customer satisfaction with a couple of links?

      >
      >I actually did a check of my last year's logs. I had about 4 million
      >mobile pageviews that year, of which 2500 were clicks to 'faq.php'.
      >
      >*weeps dramatically*
      >
      >
      so, should the recommendation to remove faq and help links stand or go?

      >
      >
      >>>- Perhaps we could also add a GAP section on
      >>> best-practice-mobile-website-disclaimer? Since Im not a lawyer Ive
      >>> grabbed some unreadable pages from some other sites, but perhaps it
      >>> would make sense to at least provide people designing websites with
      >>> a checklist of points you generally want to have covered that are
      >>> pertinent to mobile internet? More
      >>> specifically, mobile phones are often available to children (8+) and
      >>> are a LOT less policed than PC websites. Also, people are sometimes
      >>> not aware of the hidden costs of mobile site browsing. With some
      >>> current GPRS packages, downloading one MP3 could cost you $50. (more
      >>> specifically, a postpaid phone, with a tiny GPRS data bundle that is
      >>> used outside of the country.)
      >>>
      >>>
      >>>
      >>>
      >>mmm...I think this is sort of out of scope.
      >>
      >>
      >
      >A matter of perspective? Who said GAP was only technical in nature? It's
      >your call but I would consider GAP to be an excellent place to give
      >useful tips to 'a developer who is entering the mobile world'. Im not
      >saying you should add all kinds of generic legal disclaimers, but
      >pointing to the two (and perhaps there are more) mobile-specific things
      >might be worthwhile.
      >
      >
      interesting. You may have a point. Yet I would find it funny if an HTML
      styleguide was telling me to put a disclaimer/copyright notice on the
      page. After all, that's none of their business.
      On the other hand, mobile is different from the web. I think we said it.
      What did you write on your site?

      "[LEGAL_DISCLAIMER] Consider a notice on your site that mentions the
      possible cost of service"

      ?

      wouldn't this conflict with the practice not to add help, faq and about
      links?

      >
      >
      >>>- Some advice on treatment of jpegs perhaps? While building my imager
      >>> for example I found that a lot of programs (photoshop, for example)
      >>> include all EXIF data by default. EXIF data can drag down images by
      >>> over 6kB, leaving 4kb for actual image data. Not good.
      >>>
      >>>
      >>>
      >>>
      >>this is interesting. Can you draft a practice about this? something
      >>like "Beware of programs for
      >>graphic production" ?
      >>
      >>
      >
      >Certainly. Will give it some more thought (not this weekend I expect,
      >sorry, busy). One extra one: jpegs can contain tags ('Made by Marten!')
      >next to real exif data, but tags confuse a LOT of phones.
      >
      >Most NEC's will not display tagged jpegs.
      >
      >
      waiting for the text. I am already adding something today

      Some image editors (even popular ones)
      are adding extra information in JPEG
      pictures through 'tagging' and/or a standard called EXIF. This may
      increas the size of pictures (and, correspondingly, download times).
      On some devices, pictures may not be displayed at all (Nec devices
      are known to have problems with 'tagged' pictures).
      Developers should maje sure that their software can produce
      JPEG pictures without extra information and minimal in size

      >
      >
      >>>- Logo dimensions should perhaps be listed? I find that 10x2 aspect
      >>> ratio is best, anything more should be avoided. (in tune with the
      >>> navbar, it just adds weight)
      >>>
      >>>
      >>>
      >>>
      >>can you write a few line as an addition to NO_SPLASHSCREEN?
      >>
      >>
      >
      >Will do, monday probably.
      >
      >
      thanks

      >
      >
      >>Very valuable. Thanks a lot
      >>
      >>I can give you credits in the GAP document if you wish
      >>
      >>
      >
      >If you feel I've earned them I wouldn't mind. Thanks.
      >
      >Time for my weekend to start. Have a good one.
      >
      >
      and you

      thanks

      Luca
    • Luca Passani
      ... I think it depends on whether you are doing adaptation or not. I still think that it is not a good choice for LCD though. I will create a test page one of
      Message 32 of 32 , Oct 7, 2006
        sirshannon wrote:

        >A few points/questions, to Luca and everyone else with knowledge or
        >opinions:
        >
        >1. Why no external CSS? If it is handled (and seems to be in almost
        >all cases I have tested), then it will tend to save bandwidth for the
        >mobile device (thanks to caching). It is not guaranteed but the plus
        >side of external CSS outwieghs the drawbacks *in my experience*.
        >
        >
        I think it depends on whether you are doing adaptation or not. I still
        think that it is not a good choice for LCD though. I will create a test
        page one of these days and ask you and to test with devices and evaluate
        visually the differences in rendering...

        >2. Have you seen how the Weblogs, Inc sites are now handling mobile
        >users? It is the best I've seen: You use their normal URLS ( like
        >http://engadgetmobile.com ) and the server does a browser detect and
        >serves a mobile page or normal page. You can also force the mobile
        >version by adding an "m" subdomain ( http://m.engadgetmobile.com ).
        >At the bottom of every mobile page, there is a "view full version of
        >[sitename]" link. This seems to cover the most territory of the
        >implementations I've seen (and used), the most important of which is
        >that when browsing a non-engadget page on your mobile, if you click a
        >link to an engadget page, you'll (theoretically) get a mobile page,
        >not the desktop page. All the Weblogs, Inc sites have this
        >functionality now: Engadget, AutoBlog, TUAW.com, etc.
        >
        >
        OK, I think I understand what you are saying and I think you are
        actually right. What I wanted to say DIFFERENT_URL was really to make it
        clear that mobile and web experience should be different because the
        media is different. Neither you nor Marten disagree with this, as far as
        I understand. You disagree with having to have two separates URLs. So I
        think I will change this practice as follows:

        [DIFFERENT_MEDIA] Do not serve a website to a mobile device and do not
        serve a mobile site to a web browser.

        Rationale: Web and Mobile are different medias. Accessing a fully
        fledged web site on a mobile device is likely to be catastrophic for
        user-experience. On the other hand, accessing a mobile site with a web
        browser will hardly provide the kind of sophisticated look and feel that
        today's internet users have grown accustomed to. Web and mobile sites
        should be designed separately with separate objectives in mind.

        Practice: if adaptation is not possible, two different URLs should be
        provided: one for the website and one for the mobile site. While
        "www.organization-name.*" is the typical choice for website,
        "wap.organization-name.*",
        "mobile.organization-name.*", "m.organization-name.*" and "www.
        organization-name.*/mobile/" are popular choices for mobile. Lately, a
        new Top-Level domain called '.mobi' (pron.,dot-mobi) has been created to
        make the purpose of the site clear because of the URL itself. In that
        case, the mobile site URL would be "organization-name.mobi".
        If adaptation is possible, a popular approach is to look for hints in
        the HTTP request to understand the nature of the client. Requests coming
        from mobile devices are redirected to the mobile site, while request
        from web clients are redirected to the web site. The advantage of this
        approach is that a unique entry point to both applications is mainatined.
        The techniques to recognize and redirect browsers can be found at [REDIRECT]

        Of course, REDIRECT is the link to the WirelessFAQ page which explains
        how to do redirect.

        Anyone who disagrees?

        >3. I think recommending a "disclaimer" would be a good idea for any
        >page that has *pricing* or *media downloads* because in the UK and the
        >US, and probably everywhere, eventually, this sort of disclaimer is
        >legally required. HOWEVER, I think it may be out of scope of the GAP
        >document, depending on the target audience. Will anyone selling media
        >on mobile use this document as their main resource? I'm not sure.
        >
        >
        I think there are points both for and against this practice. What about
        something like:

        [CONSIDER_DISCLAIMER] Consider adding a disclaimer and cost info.


        >4. Thank you for taking the time to do this, Luca. It looks like a
        >lot of time and effort went into it.
        >
        >
        it was and it wasn't. After one year spent with W3C, I had a pretty
        clear understanding of what it was needed and it came flowing. I just
        needed to avoid the traps W3C has fallen into.

        Luca

        >
        >
        >
        >--- In wmlprogramming@yahoogroups.com, Luca Passani <passani@...> wrote:
        >
        >
        >>Marten van Wezel wrote:
        >>
        >>
        >>
        >>>Hey Luca, All,
        >>>
        >>>First of all, good work so far on Gap.
        >>>
        >>>
        >>>
        >>>
        >>thanks
        >>
        >>
        >>
        >>>Let me first adress the discussion Ive seen so far.
        >>>
        >>>
        >>>
        >>>
        >>>
        >>>>here is the point. So, if you do one web, then one could send a
        >>>>
        >>>>
        >web link
        >
        >
        >>>>by email to a friend who reads it on a mobile device and opens a
        >>>>
        >>>>
        >mobile
        >
        >
        >>>>browser to access it. In order to be consistent with one web, you
        >>>>
        >>>>
        >should
        >
        >
        >>>>actually be able to do the redirect/adaptation also on those deep
        >>>>
        >>>>
        >links.
        >
        >
        >>>>I think this would be one of those 80/20 features that fall into the
        >>>>wrong side of the equation: a lot of extra work for virtually zero
        >>>>
        >>>>
        >gain,
        >
        >
        >>>>as you rightly point out.
        >>>>I think that I right compromise between reality and giving new-born
        >>>>mobile developers a feasible solution is:
        >>>>
        >>>>- 2 separate URLs if you cannnot do adaptation
        >>>>- if you have adaptation, you can go ahead and create 2 sites,
        >>>>
        >>>>
        >but make
        >
        >
        >>>>sure the 2 entry points can re-direct to one another in case the
        >>>>
        >>>>
        >wrong
        >
        >
        >>>>type of browser is trying to access the site
        >>>>
        >>>>
        >>>>
        >>>>
        >>>First, I disagree with this one, since as we all (?) know, very few
        >>>standard websites will load, let alone parse semi-intelligibly on
        >>>
        >>>
        >mobile
        >
        >
        >>>devices.
        >>>
        >>>
        >>>
        >>>
        >>this is what I am saying. Make sure that mobile devices get mobile and
        >>web servers get to websites.
        >>
        >>
        >>
        >>>
        >>>
        >>>
        >>>
        >>>>Alternatively, one might have one entry point, redirect to the
        >>>>appropriate version and just live with the fact that some users
        >>>>
        >>>>
        >may once
        >
        >
        >>>>every blue moon get the wrong version. Also, this opens up a conflict
        >>>>between users of advanced browsers like Safari (who may want the web
        >>>>version) and the content provider (who may want to send them to the
        >>>>wmobile version).
        >>>>I know this sounds like academic not-picking. Since GAP is born as an
        >>>>alternative to W3C BP, it has to rely on solid ground and face all of
        >>>>this. If one admits one-web, they will find it in the way obstructing
        >>>>vision each and every time. So it's much more sensible (and
        >>>>
        >>>>
        >simple) to
        >
        >
        >>>>deny one-web, and then explain how to solve specific issues with good
        >>>>practices.
        >>>>
        >>>>
        >>>>
        >>>>
        >>>The question here perhaps is how 'minimalist' the GAP approach should
        >>>be. I get the point about LCD, I think, and (obviously?) personally Ive
        >>>advanced a bit beyond LCD, however maybe one thing that could solve the
        >>>argument is to recognise that it is not hard for the WURFL people to
        >>>build a very very basic monolithic site switcher.
        >>>
        >>>
        >>>
        >>>
        >>We all agree about this, but you see, one of the main points of GAP is
        >>that, no matter how much you push people to do adaptation, someone will
        >>do LCD anyway. GAP tells you what the best solution is with LCD and
        >>makes you smell the coffee about how much better you could do with
        >>adaptation. Of course, WURFL users don't need to be told this anyway,
        >>but new comers to mobile development may.
        >>
        >>
        >>
        >>>More specifically, Im sure I could whip up a php 'index.php' paired
        >>>
        >>>
        >with
        >
        >
        >>>a 'wurflrefresh.php' that would download wurfl and strip out everything
        >>>except the browser detection.
        >>>
        >>>'If phone, then include_once('phoneindex.php'), else
        >>>include_once('pcindex.php'). I realise GAP is perhaps not the place to
        >>>start storing code snippets, but even newbie programmers that don't
        >>>
        >>>
        >have
        >
        >
        >>>the time/skills/heart to build a true adapting site could easily add a
        >>>prepackaged index switcher.
        >>>
        >>>
        >>>
        >>>
        >>very good. The idea here is that you go ahead and create a wikipage
        >>
        >>
        >with
        >
        >
        >>your solution. I will point to that from GAP. The document stays self
        >>contained and developers know where to go and get the good stuff the
        >>
        >>
        >day
        >
        >
        >>they need it.
        >>
        >>
        >>
        >>>
        >>>
        >>>
        >>>
        >>>>this is a good idea. So, the GAP is meant to be some kind of
        >>>>
        >>>>
        >"survival
        >
        >
        >>>>kit" for those who won't do adaptation no matter what. In the
        >>>>
        >>>>
        >process,
        >
        >
        >>>>they should understand the value of adaptation and giving them
        >>>>
        >>>>
        >specific
        >
        >
        >>>>clues about to do it is good. What about writing a section about
        >>>>resizing pictures dynamically?
        >>>>It would fit nicely here:
        >>>>
        >>>>http://www.passani.it/gap/#SMALL_PICTURES
        >>>>
        >>>>the reference could lead to your nice ImageServer and also the
        >>>>
        >>>>
        >other PHP
        >
        >
        >>>>utility from Marten that I intend to publish...
        >>>>
        >>>>
        >>>>
        >>>>
        >>>I plan to spend more time on mine soon enough, but yeah it'd be a fine
        >>>addition already I would say.
        >>>
        >>>
        >>>
        >>>
        >>sure
        >>
        >>
        >>
        >>>Additionally, you could also just ask developers to use TABS not SPACES
        >>>to dev-format their code.
        >>>Also-also, firefox contains an awesome 'view formatted source'
        >>>
        >>>
        >extension
        >
        >
        >>>that will re-render ('indent') a webpage back to readable from even
        >>>single-line mode.
        >>>
        >>>
        >>>
        >>>
        >>got a URL?
        >>
        >>
        >>
        >>>Now my personal comments on GAP:
        >>>
        >>>- I would humbly suggest you shorten your 'intro' document. It's a huge
        >>> read, and while I get some of the points you make, you reiterate
        >>>
        >>>
        >a lot
        >
        >
        >>> of them in the actual GAP document, which made the excersise of
        >>> reading the intro a bit redundant. Also I got the impression you
        >>> really had some type of personal vendetta against the W3C.
        >>>
        >>>
        >>>
        >>well, I had to draw the energy to write such a long document
        >>
        >>
        >somewhere :)
        >
        >
        >>Jokes apart, I have nothing personal against BPWG, but I certainly was
        >>disappointed at times
        >>
        >>
        >>
        >>>I realise
        >>> you philosophically disagree with them on quite a few points, so
        >>>
        >>>
        >do I,
        >
        >
        >>> but you might be coming off a bit too harsh? My personal impression
        >>> there, do with it what you will.
        >>>
        >>>
        >>>
        >>>
        >>of course. I always will.
        >>
        >>
        >>
        >>>- 10KB as a baseline doesn't jive to well in my mind with '120x120'.
        >>> Essentially, my experience is that if you only have one 120x120
        >>> picture on a page, you only really need about 6kb total
        >>>
        >>>
        >(pic+html). If
        >
        >
        >>> you lower your limit to 6Kb you would include quite a few phones that
        >>> are excluded otherwise.
        >>>
        >>>
        >>>
        >>>
        >>10kb is the maximim recommended for the baseline. If you really want
        >>responsive services, one should keep it under 2kb. Of course, this
        >>didn't go down well with W3C and one-web, so 10kb was some sort of
        >>compomise. I think 10kb is reasonable also for GAP, because one may
        >>
        >>
        >want
        >
        >
        >>to render a couple of pictures here or there or a long menu and still
        >>stay within the GAP....
        >>
        >>
        >>
        >>>- Why would you require tables? I hesitate to say this but except for
        >>> very specific situations I would consider using tables in mobile
        >>> websites as bad practice. More specifically, table columns. To use
        >>> tables for variously colored backgrounds might be the exception
        >>>
        >>>
        >there,
        >
        >
        >>> but you would need to pair that with CSS, which you didn't require.
        >>> (or did XHTML-MP include CSS per definition?)
        >>>
        >>>
        >>>
        >>>
        >>XHTML-MP includes CSS by definition, but I do say that there should be
        >>no *external CSS*, while internal CSS should be kept simple.
        >>The point about table is that if a developer wants to show:
        >>
        >>| Roma-Juventus | 1-1 |
        >>| Milan - Inter | 0-1 |
        >>
        >>they should be able to do it.
        >>Anyway, even the T68i back in 2002 had basic table support, so this is
        >>not much of a restriction.
        >>
        >>
        >>
        >>>- As for the 'login' stuff, well same as I said on another note in this
        >>> discussion, I find that you are overestimating the amount of phones
        >>> that properly handle and store cookies. Most phones that do handle
        >>> cookies at all drop them the moment you reset the phone. Especially
        >>> when you depend on them, they are not safe to use. Plus, I feel the
        >>> majority of phones does not use cookies at all.
        >>>
        >>>
        >>>
        >>>
        >>this is excellent discussion. In the thread you mention I just
        >>challenged your figures. So, let's see what the figures are, understand
        >>what is sensinble to do in practice and what we will be left with is *a
        >>practice*
        >>
        >>
        >>
        >>> Additionally I would suggest you add a reference to session
        >>> management, where you link a username, password to a MD5 session
        >>> variable. That way, the user logs in once, and gets pointed to a page
        >>> that says 'you are now logged in. It is advised you BOOKMARK THE NEXT
        >>> PAGE. (where the next page would be
        >>> site.com/index.php?sid=839487987a98f798qhf98adsh)
        >>>
        >>>
        >>>
        >>>
        >>This looks like a great entry for the WirelessFaq which I would gladly
        >>point to from the GAP!
        >>
        >>
        >>
        >>> This is the functional equivalent of storing a cookie on your phone,
        >>> yet bookmarks rarely ever get wiped, and work everywhere.
        >>>
        >>>Okay thats it for my comments. Now my personal additions:
        >>>
        >>>- Pagers. I find that users always want to know 'where they are at'.
        >>> This means that if you have want to show them (the choice of) more
        >>> content than can fit on one page, they should not only see a pager
        >>> ('next page/prev') but also one that shows them 'page 1 out of 20'
        >>>
        >>>
        >>>
        >>mmm...I don't like this. For a GAP baseline device this information
        >>would clutter the interface.
        >>On a device with a larger screen, it may make sense. This makes your
        >>suggestion a candidate for adaptation but not LCD. I think this is
        >>covered already here to some extent:
        >>
        >>http://www.passani.it/gap/#NO_TOP_BAR
        >>
        >>I can expand it to make it clearer and include your page suggestion
        >>though (in fact I just did. Thanks).
        >>
        >>
        >>
        >>>- Avoid redundancy wherever possible. Adding 'about' 'help' 'faq' links
        >>> to all pages of your site is useless (if those links are
        >>> NON-contextual, of course. If help leads to the current page help,
        >>> then thats another matter).
        >>>
        >>>
        >>>
        >>>
        >>agreed. This looks like a new practice NO_REDUNDANCY. It makes a lot of
        >>sense for baseline devices.
        >>http://www.passani.it/gap/#NO_REDUNDANCY
        >>
        >>
        >>
        >>>One could even argue for removing the logo off all pages except
        >>>
        >>>
        >your homepage.
        >
        >
        >>agreed again
        >>
        >>http://www.passani.it/gap/#NO_SPLASH_SCREEN
        >>
        >>
        >>
        >>
        >>>- If feedback mail links are part of your business model (i.e. you
        >>> *gasp* care for what your users think), then it is often a good idea
        >>> to add subject and body code that is relevant to the coder. One
        >>>
        >>>
        >of the
        >
        >
        >>> most frustrating experiences as a 'helpdesk' for my own site was not
        >>> knowing what page was giving the user trouble. 'Yeah, the page with
        >>> the doohicky and then some OK thingy' is tough to decode, a <a
        >>>
        >>>
        >>>
        >href=\"mailto:helpdesk@...?subject=UpdatePassword.php&Body=".urlencode($userid.$nickname.$useragent)."..>mail
        >
        >
        >>> helpdesk</a> might not always actually add those headers (with crappy
        >>> mailclients) but if it does, they are a godsend.
        >>>
        >>>
        >>>
        >>>
        >>the problem is that I cannot assume baseline device has an email client
        >>and that it's correctly configured.
        >>
        >>
        >>
        >>>- Do not waste time on manual pages, they will not get read. Just
        >>>
        >>>
        >make a
        >
        >
        >>> dummy 'help' page and weep at the (single digit) amount of pageviews.
        >>>
        >>>
        >>>
        >>>
        >>great minds think alike, I had just said basically the same while
        >>explaining:
        >>
        >>http://www.passani.it/gap/#NO_REDUNDANCY
        >>
        >>
        >>
        >>>- Perhaps we could also add a GAP section on
        >>> best-practice-mobile-website-disclaimer? Since Im not a lawyer Ive
        >>> grabbed some unreadable pages from some other sites, but perhaps it
        >>> would make sense to at least provide people designing websites with
        >>> a checklist of points you generally want to have covered that are
        >>> pertinent to mobile internet? More
        >>> specifically, mobile phones are often available to children (8+) and
        >>> are a LOT less policed than PC websites. Also, people are sometimes
        >>> not aware of the hidden costs of mobile site browsing. With some
        >>> current GPRS packages, downloading one MP3 could cost you $50. (more
        >>> specifically, a postpaid phone, with a tiny GPRS data bundle that is
        >>> used outside of the country.)
        >>>
        >>>
        >>>
        >>>
        >>mmm...I think this is sort of out of scope.
        >>
        >>
        >>
        >>>- Some advice on treatment of jpegs perhaps? While building my imager
        >>> for example I found that a lot of programs (photoshop, for example)
        >>> include all EXIF data by default. EXIF data can drag down images by
        >>> over 6kB, leaving 4kb for actual image data. Not good.
        >>>
        >>>
        >>>
        >>>
        >>this is interesting. Can you draft a practice about this? something
        >>like "Beware of programs for
        >>graphic production" ?
        >>
        >>
        >>
        >>>- Logo dimensions should perhaps be listed? I find that 10x2 aspect
        >>> ratio is best, anything more should be avoided. (in tune with the
        >>> navbar, it just adds weight)
        >>>
        >>>
        >>>
        >>>
        >>can you write a few line as an addition to NO_SPLASHSCREEN?
        >>
        >>
        >>
        >>>OK that's it for now.
        >>>
        >>>
        >>>
        >>>
        >>>
        >>Very valuable. Thanks a lot
        >>
        >>I can give you credits in the GAP document if you wish
        >>
        >>Luca
        >>
        >>
        >>
        >>>
        >>>
        >>>
        >>>
        >
        >
        >
        >
        >
        >
        >
        >As of July 14 2005, it's much easier to be banned from WMLProgramming!
        >Please fail to read http://groups.yahoo.com/group/wmlprogramming/ before you post.
        >Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.