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($user\
id.$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

Andrea Trasatti wrote:

>
>>You are right (and by the way, it didn't need to be like this with
>>WML),
>>so I would say that this point is worth discussing. Generally
>>speaking,
>>I would say that the diminished number of clicks still makes for a
>>better user experience in spite of the round trip. This is unless
>>there
>>is a very slow connection.
>>If you feel like rephrasing or adding a few sentences to improve the
>>paragraph, just post them.
>>
>>
>
>I have to admit that this is a tough topic.
>I agree with Luca's point if you are submitting a bunch of
>information via WAP such as name, address, social security number, etc.
>
>On the other side, reading the text, someone could interpret that
>even simple forms should be split. Think for example to a login page
>in which you have 3 fields, username, password and a drop-down to
>pick the service you want to login (say, e-mail, calendar, IM,
>other). I would not split it into two pages, because the entire form
>is not too complex and splitting would not save many clicks, might
>even be some extra clicks for some browsers.
>
>I think the general meaning is correct, but should be made more
>specific, should provide a hint about when it's better to have all in
>one page and when to split it.
>
>
I will reference to testing. Build a prototype of the forms and see
which one non-techie users find the easiest

Luca

Andrea Trasatti wrote:

>
>I have to admit that this is a tough topic.
>I agree with Luca's point if you are submitting a bunch of
>information via WAP such as name, address, social security number, etc.
>
>On the other side, reading the text, someone could interpret that
>even simple forms should be split.
>
I added this:

Creating usable forms is generally difficult. Developers are encouraged
to do usability tests with real users ([TESTING <#TESTING>]) as early as
possible in the lifecycle of the application, possibly with the help of
prototypes.
It cannot be ruled out that different forms are required to optimize
usability on different classes of devices. This is consistent with the
general idea that adaptation drammatically improves the success of
mobile applications.

Luca

On 9/30/06, Luca Passani <passani@...> wrote:
> I also know for a fact that Sprint-Nextel and Cingular
> support cookies in the US.

Cingular has not passed simple cookie tests using HttpConnection via
J2ME.  Is the mobile browser a different story.

I also have empirical evidence that the cookie size is more limited
via mobile than with PC browser.

My experience (via J2ME) has been that cookies will almost work but
not quite on 80% of the phones :-(

Il giorno 01/ott/06, alle ore 08:19, Luca Passani ha scritto:
>>
> Absolutely, let's work on it. IMO the right approach should be:
> - to demonstrate that cookies work in 80% or more of the cases.
> - Tell developers that cookies generally work, but there are
> exceptions
> - give developers a good basis toturn to their carrier, point at
> GAP/WirelessFaq and say "look, you don't support cookies properly.
> This
> should be fixed"
>
> So, starting with Italy: TIM, Vodafone and H3G support cookies. Not
> sure
> about Wind. Andrea, do you know more? I also know for a fact that
> Sprint-Nextel and Cingular support cookies in the US.
> Other reports?
>
> We have i-mode folks here. Can they shed any light about i-mode either
> european or japanaese?

I did quite some testing about 1 year ago. With this I mean testing
about 15 XHTML Basic and MP devices with Openwave 6.x, Teleca/SEMC,
Nokia and other browsers.

I also took some time to write about this on the wireless FAQ and it
seems to me like it should already cover most of this conversation:
http://www.thewirelessfaq.com/
are_cookies_supported_in_the_wap_environment

Wind supports cookies as far as I remember, the instability of their
data connection is a much bigger issue than cookies themselves.

On the other side I verified myself some untrackable problems with
the Samsung Z107 (TIM used to sell it a lot last year as a feature
phone). The browser generally speaking supports cookies, but
sometimes simply did not send it. I added quite a few logs and test
pages. In a normal navigation I would say that the phone would not
send the cookie once every 4-5 pages and it's not a page or content
issue because when I tracked a nocookie, pressing reload would
deliver the cookie most of the times. I added a bunch of logs and
built the links to make sure that the site would gracefully manage
the situation.

Honestly, I would not bother this bad behaviour that I haven't seen
on other sites and if the phone hadn't been a big seller in Italy, I
would not have bothered.

J2ME is certainly a totally different story, it could be a good or
bad implementation in the HTTP API's or a memory problem or other.

I think it would be worth to split the two topics between "standard
WAP browser" and "HTTP libraries".

Andrea Trasatti
My Blog: http://trasatti.blogspot.com/
W3C invited expert

Il giorno 30/set/06, alle ore 09:43, Luca Passani ha scritto:

> Marten van Wezel wrote:
>
>
>>
>> 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?

An interesting new function in PHP 5:
http://www.php.net/php_strip_whitespace

Andrea Trasatti
My Blog: http://trasatti.blogspot.com/
W3C invited expert

Il giorno 30/set/06, alle ore 09:43, Luca Passani ha scritto:

> Marten van Wezel wrote:
>
>> - 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!

We already have this page in the FAQ:
http://www.thewirelessfaq.com/
are_sessions_supported_in_the_wap_environment

It also links to the FAQ about cookies. I saw another interesting
thread on the list about user tracking, I would like to integrate it
in the FAQ, still need to decide if it should be part of this page or
not.
I also wanted to write an FAQ about user tracking from a web site,
for example, sending a push message with a session, specifically. It
would also cover alternative automatic login methods, for example.
Suggestions are welcome.


>> - 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" ?

I think it would be good to give hints about removing EXIF and other
optional information that would simply make the images heavier rather
than simply saying "avoid photoshop" or anything. I'm sure you can
edit or remove that information from Photoshop or other image editors.

Andrea Trasatti
My Blog: http://trasatti.blogspot.com/
W3C invited expert

Il giorno 29/set/06, alle ore 11:22, affirmativeactionman ha scritto:

> Hi MArten,
>
> I suppose I should've been more specific in my original post. Yes, the
> WAP-Push SMS does arrive on the phone. It's when you click the link,
> some phones download and play the file without any problem, while on
> my test Nokia 6600, I get a "Services: Reply Unknown". I'd like to
> know exactly how I go about specifying content type to the phone so
> that I can deliver different kinds of content via WAP Push, MP3; 3GP;
> etc... I'm a bit of a newbie to the whole content delivery game and
> I've searched high and low for an article that explains in simple
> English how to go about distributing content via WAP-Push.

Hello Charles,
	 on The Wireless FAQ are a couple of pages that you can read.

Session handling and URL Decoration:
http://www.thewirelessfaq.com/
are_sessions_supported_in_the_wap_environment

Content Delivery:
http://www.thewirelessfaq.com/content_delivery

I suggest that you send push messages with URL Decoration to
recognize and track your users.
Apply the suggestions in the "Content Delivery" page picking your
favorite delivery method.
The most important thing is, of course, discovering what the device
supports and deliver the appropriate content. WURFL can help here.
When the content is not supported an error message should be
displayed BEFORE the download, for example, you send the push
message, the user downloads your WAP page and you should a link to
download OR an error message such as "Sorry, your phone is not
supported". Up to you how to manage users, subscriptions and so on.

Andrea Trasatti
My Blog: http://trasatti.blogspot.com/
W3C invited expert

People, I have a few site updates to do, but I am swamped. Please allow
me a few extra days. Thanks

Luca

You might want to reconsider cookies on mobile phones - in most cases
you have to turn on URL rewriting.

This is because you can be roaming with your mobile in a vehicle and if
the phone switches from a 3G network to a 2G network (or to another
provider's network) during this time, chances are you will come in from
a totally different gateway.  The different gateway won't know anything
about the device and won't provide the same faked cookie for the device
if the device doesn't support cookies.  All the phones we tested here at
Hyro seem to support url rewriting as long as the url doesn't get too long.

(a gotcha; If a clustered Tomcat 5.5.x with session replication gets a
cookie from a device, URL rewriting is ignored AND the cookie request
will have no HttpSession....annoying!).

Cheers, Murray

Thanks Murray, this is all good thinking.

People. Shall we add a practice that says:

"[COOKIES] Rely on cookies. Be aware that they may not always work as
you expect"?

After all, only certain functions require cookies to work 100%, while
others may do with crippled cookies and/or degrade gracefully if cookie
is not supported.

- logins: if the user is recognized 80% of the times, that's still a
biggain over giving up on recognizing the user altogether

- sessions: this may be too unreliable for cookies. Alternatives:
URL-REwriting or tracking the header with the unique ID (a lot of
gateways provide that).

- remembering user previous choices: good enough

Other usages? should we also have a recommendation to contact one's
carrier and/or device manufacturer and tell them that their cookie
support is poor?

Luca


Murray Brandon wrote:

>You might want to reconsider cookies on mobile phones - in most cases
>you have to turn on URL rewriting.
>
>This is because you can be roaming with your mobile in a vehicle and if
>the phone switches from a 3G network to a 2G network (or to another
>provider's network) during this time, chances are you will come in from
>a totally different gateway.  The different gateway won't know anything
>about the device and won't provide the same faked cookie for the device
>if the device doesn't support cookies.  All the phones we tested here at
>Hyro seem to support url rewriting as long as the url doesn't get too long.
>
>(a gotcha; If a clustered Tomcat 5.5.x with session replication gets a
>cookie from a device, URL rewriting is ignored AND the cookie request
>will have no HttpSession....annoying!).
>
>

Hi,

What different possibilities there is to do url_rewrite in other than
Apache with mod_rewrite module.

With help of Google I found this project
http://www.tuckey.org/urlrewrite/ which does what mod_rewrite do in
Apache for any J2EE compliant web application server.

Is there any for the following servers:

IIS
IBM Websphere
Apache Tomcat
Sun Java System Web Server
BEA WebLogic
IBM WebSphere

- Markus Kalliola

> >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 was actually going to make that suggestion, because I find our logs
infinitely useful.  Here's what I religiously keep an eye on in logs:
- Device type
- Content type delivered (XHTML vs. WML)
- Phone screen size
- Unrecognized devices

Device Type is probably the most important, because I want to be sure
that our site performs extremely well for the majority of our users.
The 'Unrecognized devices' I find really important lately, because as
new phones come into market I want to be sure to support them, and I
want to keep up with the newer devices to deliver them the right
content.
Tangentially: Is there any mobile analytics software out there?  I
rolled my own on top of WebTrends, but If there's something else out
there I'd love to try it.

I do use the WURFL XML for device detection.  I'm sure stuff like this
has been posted here before, but if anyone's interested, I can pull
some numbers next week and see the percentage of recognized devices
we're getting with WURFL (as well as content-type, and so on).

> >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.

Definitely.  Not all web site authors are programmers (nor should they
be), so it would be great to have a simple tool for people who just
want to split their content by device type -- maybe one for the
desktop browsers, one for XHTML-MP, and one for WML.

I like that quick site switcher, but for general use I was wondering
if something like an Apache module similar to mod_rewrite would be a
good, "standard" way to go.  Would something like that be useful to
anyone else?


Jesse

Hello

The result :

SAGEM-myC5-2v/1.0 UP.Browser/6.2.3.3.g.2.106 (GUI) MMP/2.0

HTTP accept :
text/vnd.wap.wml, text/vnd.wap.wmlscript, image/vnd.wap.wbmp,
application/vnd.wap.wmlc, application/vnd.wap.wmlscriptc,
application/vnd.wap.multipart.related,
application/vnd.wap.multipart.mixed, application/vnd.phonecom.mmc-
wbxml, application/octet-stream, application/vnd.oma.drm.message,
text/plain, text/css, image/bmp, image/gif, image/jpeg, image/png,
application/vnd.wap.sic, application/vnd.wap.slc,
application/vnd.wap.coc, application/vnd.wap.connectivity-wbxml,
application/vnd.wap.xhtml+xml, text/html, application/smil,
application/vnd.wap.mms-message, audio/wav, audio/x-wav,
audio/iMelody, audio/midi, audio/mid, audio/x-midi, audio/x-mid,
audio/amr, audio/x-sagem1.0, audio/x-sagem2.0, audio/mp3, audio/x-
mp3, audio/mpeg3, audio/x-mpeg3, audio/mpeg, audio/x-mpeg,
audio/mp4, audio/x-mp4, audio/mpeg4, audio/x-mpeg4, audio/aac,
image/wbmp, image/svg+xml, text/x-iMelody, text/x-vCard, text/x-
vCalendar, text/vnd.sun.j2me.app-descriptor, video/mp4, video/x-mp4,
video/mpeg4, video/x-mpeg4, video/mpeg, video/x-mpeg, video/3gpp,
application/x-jam, application/java, application/java-archive,
application/vnd.uplanet.bearer-choice-wbxml, */* -

In the WURLF 'video_mp4' => false and 'ringtone_wav' => false.

If it can help grow the WURLF...

What is the best method for give information to be integrated to the
WURLF ?

Denis

PS : Sorry for my poor English, I'm French...


--- In wmlprogramming@yahoogroups.com, "denis" <ds@...> wrote:
>
> Hello
> I find a Sagem Myx5-2, I will test and give you a feedback.
> Denis
>
> --- In wmlprogramming@yahoogroups.com, "denis" <ds@> wrote:
> >
> > Hello,
> > I'm interested in delivering screensavers,
> > wallpapers,ringtone and videos via WAP-Push using WURLF and PHP
> > (Great Script !).
> > But I have seen some information which seems to be wrong (I
> > suppose) :
> > For example :
> > Samsung X480 : 'directdownload_support' => false ??? Is it
> > possible ?
> > Sagem Myx6-2 : 'directdownload_support' => false ??? Is it
> possible ?
> > (SAGEM-myX6-2/LT5,1D Profile/MIDP-2.0 Configuration/CLDC-1.1
> > Browser/UP.Browser/7.1.0.f.1.115 (GUI))
> > Sagem Myx5-2 : 'directdownload_support' => false ??? Is it
> possible ?
> >
> > directdownload_support = It's a mobile which support to store a
> > picture or ringtone with a simple link like :
> > <a href=image.gif>Download</a>
> > , Is it correct ?
> >
> > Is it because the WURLF is not updated ?
> > Lots of company propose some product for this modeles, how do
> they ?
> > I think I don't understand a thing...
> > When the information :
> > 'wallpaper_preferred_width' => 0
> > It's because is not compatible or is it because it's unknown ?
> > Thanks a lot for your help.
> > Denis
> >
>

Thanks Jesse,

please post here your findings about new devices here.

> I can pull
> some numbers next week and see the percentage of
> recognized devices we're getting with WURFL
> (as well as content-type, and so on).

please do. I am very interested. Where are you based? which geographies is your
application serving?


  > I like that quick site switcher, but for general use I was wondering
  > if something like an Apache module similar to mod_rewrite would be
  > a good, "standard" way to go. Would something like that be useful to
  >anyone else?

I would like to have a hell of a switcher distributed as standard with WURFL
evolution

Luca



Jesse Boyes wrote:

>>>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 was actually going to make that suggestion, because I find our logs
>infinitely useful.  Here's what I religiously keep an eye on in logs:
>- Device type
>- Content type delivered (XHTML vs. WML)
>- Phone screen size
>- Unrecognized devices
>
>Device Type is probably the most important, because I want to be sure
>that our site performs extremely well for the majority of our users.
>The 'Unrecognized devices' I find really important lately, because as
>new phones come into market I want to be sure to support them, and I
>want to keep up with the newer devices to deliver them the right
>content.
>Tangentially: Is there any mobile analytics software out there?  I
>rolled my own on top of WebTrends, but If there's something else out
>there I'd love to try it.
>
>I do use the WURFL XML for device detection.  I'm sure stuff like this
>has been posted here before, but if anyone's interested, I can pull
>some numbers next week and see the percentage of recognized devices
>we're getting with WURFL (as well as content-type, and so on).
>
>
>
>>>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.
>>
>>
>
>Definitely.  Not all web site authors are programmers (nor should they
>be), so it would be great to have a simple tool for people who just
>want to split their content by device type -- maybe one for the
>desktop browsers, one for XHTML-MP, and one for WML.
>
>I like that quick site switcher, but for general use I was wondering
>if something like an Apache module similar to mod_rewrite would be a
>good, "standard" way to go.  Would something like that be useful to
>anyone else?
>
>
>

On 10/2/06, Luca Passani <passani@...> wrote:
>
> People. Shall we add a practice that says:
>
> "[COOKIES] Rely on cookies. Be aware that they may not always work as
> you expect"?
>

Or:

"Cookies cannot be relied on.  But may work as expected -- and this
may be good enough for some applications."

On 10/1/06, Andrea Trasatti <andrea@...> wrote:
>
> J2ME is certainly a totally different story, it could be a good or
> bad implementation in the HTTP API's or a memory problem or other.
>

Does Opera Mini connect these two in an interesting way?

there are a lot of things for this like awstats or google analytics
but google analytics would not work on all phones and awstat is not a
good way to that. because it would not show who is online now or who
is looking which page.

I like to have a system which shows who is online now with which user
agent and looking which url. and stores this kind of stats information.

can you suggest me anything like that ? or what kind of systems do you
use for this infos.
thanks in advance.

If you want to use it for session tracking you might look at the
HttpServletResponse::encodeURL method.

Martin


-----Ursprüngliche Nachricht-----
Von: wmlprogramming@yahoogroups.com [mailto:wmlprogramming@yahoogroups.com]
Im Auftrag von mkalliol
Gesendet: Montag, 2. Oktober 2006 11:06
An: wmlprogramming@yahoogroups.com
Betreff: [wmlprogramming] url_rewrite in different environments



Hi,

What different possibilities there is to do url_rewrite in other than
Apache with mod_rewrite module.

With help of Google I found this project
http://www.tuckey. <http://www.tuckey.org/urlrewrite/> org/urlrewrite/ which
does what mod_rewrite do in
Apache for any J2EE compliant web application server.

Is there any for the following servers:

IIS
IBM Websphere
Apache Tomcat
Sun Java System Web Server
BEA WebLogic
IBM WebSphere

- Markus Kalliola







[Non-text portions of this message have been removed]

Thanks for everyone's help.
I changed the default fallback to xhtml and that fixed it for my cases. I
guess this might mean things won't work with WML devices, but I can't
actually find one around here to test with.... weird...
rob.



On 9/28/06, Raul Piaggio <mithluin@...> wrote:
>
>   Hi Rob,
>
> If you search the list you will find that I had the exact same problem
> with a SonyEricsson not that long ago (search for "ampersand hell").
>
> I ended up solving the issue by implementing a Servlet Filter that
> would fix requests that have "&" in them.
>
> I can send it over if you want.
>
> Raul
>
>
>


[Non-text portions of this message have been removed]

Maybe your web server does not have that particular mime-type configured?

This is usually the case with AMR/AMR-WB files, you need to set the
mime-type on the web server configuration files in order to be recongnized
by the phone.

Hope it helps.

Alejandro.

On 9/20/06, hertanto_i <hertanto_i@...> wrote:
>
>   Hi,
>
> Thanks for the reply tom.
> I don't think it's a problem of playing the file.
> The wurfl file says that it's able to play it.
> It's when i try to download it using the phone browser that i got
> the error.
>
> Thanks,
> klughing
>
> --- In wmlprogramming@yahoogroups.com <wmlprogramming%40yahoogroups.com>,
> tom@... wrote:
> >
> > Hi klughing,
> >
> > Some branded 3g phones, such as ones on Vodafone, only let u play
> DRM'd
> > audio files,
> > your issue could be caused by this.
> >
> > Although, after Anders mail about the N80 I'm wondering what
> Vodafone
> > would do with that if the device can't play drm'd files...
> >
> > with kind regards,
> >
> > tom
> >
> > > -------- Original Message --------
> > > Subject: [wmlprogramming] Phone browsers
> > > From: "hertanto_i" <hertanto_i@...>
> > > Date: Wed, September 20, 2006 1:39 am
> > > To: wmlprogramming@yahoogroups.com <wmlprogramming%40yahoogroups.com>
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi,
> > >
> > > I was messing around with device detection of mobile phones
> using the
> > > WURFL file and i tried sending a link that points to an audio
> file.
> > > I know the WURFL file said that that phone supports that file
> > > extension but i think the browser doesn't allow me to get that
> file.
> > > The error said something about not supporting the content type.
> > > Does this mean it's the browser's limitation? I'm using a LG
> A7110
> > > with this. WURFL said it supports .amr but when i tried
> downloading
> > > it, i got that error. Help?
> > >
> > > Thanks,
> > > klughing
> > >
> > >
> >
>
>
>



--
Alejandro Guerrieri
Magicom
http://www.magicom-bcn.net/
LinkedIn: http://www.linkedin.com/in/aguerrieri


[Non-text portions of this message have been removed]

On 9/30/06, Luca Passani <passani@...> wrote:
> I also know for a fact that Cingular supports cookies in the US.

Can I assume this applies to both wap.cingular.com and
isp[da].cingular.com?  In any event, it's probably good to be
explicit, since different services can have different capabilities.

I need following information

I'm trying to automated uaprof to wurlf and i'm using
uaprofwurflcomparator.rb

The problem is that the script always generate device with
fall_back="geneic"

An Example if i supply UAProf of k750i with is already present in
wurlf.xml and loaded to wurlf.db it genearte fall_back="generic"

As i understand the script leave generation of id and fall_back to human.

Can anyone help me on it a how to generate valid id for device and
maybe someone fix this problem with script I'm not ruby guru : ) so
please help.

BTW second problem is that script doesn't generate
actual_device_root="true" for device that not present at all in wurlf.xml

Allright, let's see.


> >>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?

Not that much for the purpose of 'tweaking the adaptation', I only keep
an eye on my main error logs and try to catch and fix rendering errors
when users report them to me.

On the flipside, I suppose that we could outline a work ethic where
people could quickly spot, patch and submit missing phones or changes to
wurfl.

> >- 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

Easy enough: efficiency. Have you ever seen a storefront with an URL?
Probably not that often. (I can remember only one instance, and URLs
have been around for AGES. Now how often do you think a storefront will
have *2* urls?

The main thing is that you need keep things as simple as 'humanly'
possible, since the barriers to get people to use mobiles for YOUR
commercial purposes are already incredibly high. (anyone who has been
involved in mobile parts commercial campains will back me on this I think)

> >- 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).

*nod* it would be a bit of a good thing, but if you intentionally go to
a site of a GENERIC company. you will probably use your PC and go to
'radbooks.com'. The impulse to look something up while you're in the bus
usually is countered by the inconvenience of mobile internet.
Only if you want mobile-specific services (ringtones?) will you start making up
your own urls.


> >- 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.

Andrea, what do you think abou the switcher, more specifically would it
be worthwhile to make some code that would only use the bare essentials
of your PHP library? Im not quite sure how much performance gain and
simplicity gain can be achieved by trying to cut it down as much as
possible.

> >>> 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?

Yeah should be no problem, although already mentioning sessionIDs MD5's
and databases might become a touch too technical for the general spirit
of the GAP as Ive seen so far?

Anyway Ill give it a shot, we can always choose to add it to either the
wireless faq or the GAP


> >>>- 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.

Exactly. Any 'default clutter' on pages should be avoided, but in
certain spots you will need to present the user with a large amount of
content, and in this case, efficient ways to present the content
database should be considered.

Since I have no personal experience in this area (yet, the company I
work for does..) Im not the best one to comment, but one thing Ive
always liked was the concept of a one-letter searchbox. Just type the
first letter of the page you want to see and hit 'go'.

This prevents the '26 option' scroll horror, or the cumbersome pulldowns
that don't always work that well.


>
> 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.

Sounds good to me.

> >>>- 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($user\
id.$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?

That depends on the type of site. If the site is a ringtone site, you
usually have not much binding with the site, and if something doesnt
work you move on to the next site.

With sites that are based on return visit (chat, date, videolog etc) you
want to be able to use all features, and people will more readily try to
help you out.

"Help it is the suck!" or similarly informative mails were, and are
mails I have to deal with sometimes. User error most of the time,
honest!

(still.. one could philosophically argue that any site that leaves room
for user error wasnt simple enough in the first place..)

> >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?

My opinion is that a faq/help link will only really be worthwhile if you
make context sensitive help. If not, you are probably better served by
just providing a helpdesk mail and trying to make the experience as
intuitive as possible in the first place.

> >>>- 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?

Too much filler, partially because I wanted to cover my ass, (chat and
date sites can be dangerous to the operator's financial health). But as
I briefly mentioned before I think it is a moral obligation for
operators to mention the amount of unseen bandwidth cost sites run up.
My chat page (for example) is basically 10kb each refresh and users have
to manually reload it each time. Which they do say 4-5 times a minute..
that adds up.

Also, a user can get scared away by an unexpectedly high phone bill,
while not paying you that much. Considering building a midp applet which
employs bandwidth saving techniques might be worth checking out.

Secondly what I did with my site's age check ('you must be 18 years or
over') is:

a/ NOT mention age limitations before they actually have to enter their
age,

b/ add age to some other part of the signup process, not give it
an important looking page by itself.

b/ If the age entered below the limit, give people a second chance (you
have to, people will get past those anyway) but flag the users. (and
also have 'we might have to watch your actions for your protection and
others).

All in all we sniff out underage chatters fairly efficiently this way.

> "[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?

I basically would advise to ECONOMISE on faq/help. Only the bare
essentials and 'quick guides' get read and/or used, so a few words of
the must-knows can be worthwhile. A complete user manual of your site
isn't.


> >>>- 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

Ill work on it soon, promise. It isn't even that much work, but Im
working about 12 hours a day on a mobile site we're releasing this week
for my job.. kinda knackered when I come home.

-Marten

Guys,

We have implemented a reasonably simple fix for session support.

Although it has been mentioned a number of times managing a session id
in the URL is natively supported in Java servlets. This means that you
don't need to go away and write your own URL rewrite - session
management framework. You can simply call the encodeURL(URL) method on
all URLs. Initially this seemed like it was going to be more work than
it was worth but as we are using the WALL tag library we simply added
this call to the try block of the doStartTag() method of the WallA class.

HttpServletResponse response = (HttpServletResponse)
pageContext.getResponse();
setHref(response.encodeURL(href));

This method basically adds the session id to the URL if cookies are
disabled on the client. Otherwise, it returns the URL unchanged.

Useful documentation:
http://java.sun.com/javaee/5/docs/tutorial/doc/Servlets11.html

Let me know if it solves your problem.

Regards,

Paul


--- In wmlprogramming@yahoogroups.com, "Joe Bowbeer" <joe.bowbeer@...>
wrote:
>
> On 9/30/06, Luca Passani <passani@...> wrote:
> > I also know for a fact that Cingular supports cookies in the US.
>
> Can I assume this applies to both wap.cingular.com and
> isp[da].cingular.com?  In any event, it's probably good to be
> explicit, since different services can have different capabilities.
>

Brilliant. I almonst wonder if I should add this to the standard WALL,
possibly as an attirbute of the document tag:

<wall:document enable_url_rewriting="true">

comments?

Luca

mnetcorporation wrote:

>Guys,
>
>We have implemented a reasonably simple fix for session support.
>
>Although it has been mentioned a number of times managing a session id
>in the URL is natively supported in Java servlets. This means that you
>don't need to go away and write your own URL rewrite - session
>management framework. You can simply call the encodeURL(URL) method on
>all URLs. Initially this seemed like it was going to be more work than
>it was worth but as we are using the WALL tag library we simply added
>this call to the try block of the doStartTag() method of the WallA class.
>
>HttpServletResponse response = (HttpServletResponse)
>pageContext.getResponse();
>setHref(response.encodeURL(href));
>
>This method basically adds the session id to the URL if cookies are
>disabled on the client. Otherwise, it returns the URL unchanged.
>
>Useful documentation:
>http://java.sun.com/javaee/5/docs/tutorial/doc/Servlets11.html
>
>Let me know if it solves your problem.
>
>Regards,
>
>Paul
>
>
>

Luca

One comment: I'm not sure I'd agree with avoiding coloured links
(OrangeWorld does this to great effect in a usable manner)...

Tom

On 28 Sep 2006, at 15:35, Luca Passani wrote:

>
> As many on this list certainly remember, I have not been very happy
> lately with the way W3C has created its best practices for mobile
> developers. Lately, I felt like I was about to go mad. The only way to
> find some peace of mind for me was to create a new set of practices
> which are:
> - based on real practice (and not on higher-goals and politics)
> - open to the community of developer and whoever else feels they
> want to
> contribute to the document
>
> Writing this document was a lot of work, but the year spent in BPWG
> helped me: I was able to focus on the different issues very precisely.
> For example, I discarded the postulate of One Web (web and mobile are
> different things no matter what W3C says). I spelled out clearly that
> adaptation is the way to go. Having said this, GAP is about LCD, i.e.
> Least-Common-Denominator one-size-fits-all XHTML MP programming. It is
> acknowledged that some developers will do LCD anyway. So, GAP is some
> kind of survival kit for those who do LCD, hoping that one day they'll
> see the light and do adaptation instead.
>
> The first public draft has gone live today:
>
> http://www.passani.it/gap/
>
> What I would like you to do is to read the spec and come with
> feedback.
> If you think some practice is missing or that some existing practice
> should be removed/modified, just post your comments here.
>
> Of course, feel free to point everyone who has questions about BP
> to GAP
> instead.
>
> One final document, those who are still wondering what BP and GAP are
> all about, may read this summary (a bit more blogging in style):
>
> http://www.passani.it/gap/intro.htm
>
> Enjoy
>
> Luca
>
>
>

--
Future Platforms Ltd
e: Tom.Hume@...
t: +44 (0) 870 0055924
m: +44 (0) 7971 781422
company: www.futureplatforms.com
personal: tomhume.org

Hello,

Thanks for use the uaprof tools!

On Tue, 03 Oct 2006 05:22:13 +0900, neroshige <neroshige@...> wrote:

> I need following information
>
> I'm trying to automated uaprof to wurlf and i'm using
> uaprofwurflcomparator.rb
>
> The problem is that the script always generate device with
> fall_back="geneic"
>
> An Example if i supply UAProf of k750i with is already present in
> wurlf.xml and loaded to wurlf.db it genearte fall_back="generic"
>
> As i understand the script leave generation of id and fall_back to human.

This script should actually set the wurfl_id and fallback to the one that
is in the WURFL.  Are you using version 1.10?

http://wurfl.cvs.sourceforge.net/wurfl/tools/uaproftowurfl/uaprofwurflcomparator\
.rb?revision=1.10&view=markup

If not download the above link and try it out.

> Can anyone help me on it a how to generate valid id for device and
> maybe someone fix this problem with script I'm not ruby guru : ) so
> please help.

Can you post your command line arguements?


> BTW second problem is that script doesn't generate
> actual_device_root="true" for device that not present at all in wurlf.xml

It can be easily changed to do that, but the question is if all UAProfs are
really the base device that should have actual_device_root set to true.

I hope this helps,
Zev

someone blogged on it:

http://wapreview.com/blog/?p=172

Luca

Tom Hume wrote:

>Luca
>
>One comment: I'm not sure I'd agree with avoiding coloured links
>(OrangeWorld does this to great effect in a usable manner)...
>
>
Someone just blogged on it and reported an excellent example

http://wapreview.com/blog/?p=172

Luca