Re: Access and communication - URLs and more

Hi All

Our site www.WordDial.com does the same as Rotans and displays the relevant content dependant on the device accessing the URL and works well for us.

WordDial are promoting going directly to whatever you are looking for by entering the topic/subject/service directly as a .com URL using numbers rather than letters; e.g News becomes 6397.com.

We have over 8000 .com URL's that spell virtually everything you can imagine in numbers.  Currently we are testing in New Zealand, so much of the content currently is NZ centric, but we are going Global in 2006 using dynamic portals that will be created on the fly when the URL is entered based on a users device, location and history.

I am interested to get any feedback frm you on the WordDial System of getting directly to what you want wherever you are.  
Give it a try on your mobile phone...Free = 3733.com !

Cheers,
Graham Saywell



  ----- Original Message ----- 
  From: Rotan Hanrahan 
  To: Nicolas Combelles ; public-bpwg@w3.org 
  Sent: Saturday, August 06, 2005 2:52 AM
  Subject: RE: Access and communication - URLs and more


  Identifying the device is what technologies like CC/PP and UAProf are intended to do. Widespread support for such technologies will facilitate the use of single URLs, removing the need to have differentiating URL paths or DNS names. In your first use case, consider the possibility of sending a representation intended for a big screen workstation to a small screen device with limited memory. This situation is likely to fail. Howver, send a URL to a big screen device and get a big screen representation, and then send the same URL to a small screen device and get a small screen representation, this seems like a more useful situation and less likely to errors.

  You may wonder about the reverse. Suppose I am a small screen user and I want to show my big screen friend what I have just seen on my small screen device. Is there a way for me to do this? Perhaps. But there is still the possibility that the big screen device wouldn't be able to display the content that was intended for the small screen. (For example, many big browsers can't display WBMP images that are commonly used in WML mobile devices.)

  I think there are just too many problems created when you expect a representation for one device to be supported by another device. I think the case where the representation of a URL is presented according to the conditions observed in the delivery context is the more realistic default case. We would need a new technology to be able to support interoperable representations, and that would require that all browsers have all the same interfacing abilities, which is unrealistic.

  I accept there may be some "common formats", such as raw text, that has a wide-enough support accross a range of devices to be useful as a lingua franca, but the richness of the presentation would be mostly lost.

  As for defining "content", an issue to consider is the meaning of content and the meaning of "representations of content". When we talk about adaptation, we're talking about creating representations. Somewhere in the background is the original content that the author created, and hopefully that original content contains enough material to support the various representations that will be required.

  ---Rotan

  PS They've just reactivated the Permit Navigation option on the iMode channel. We really should stop experimenting with our site :-)

  -----Original Message-----
  From: Nicolas Combelles [mailto:nicolas.combelles@apocope.com]
  Sent: 05 August 2005 13:57
  To: Rotan Hanrahan; public-bpwg@w3.org
  Subject: RE: Access and communication - URLs and more


  >> But then, you have to identify clearly the device to avoid displaying the PC interface to a mobile and vice versa.

  Of course this sentence apply to the case where you have a different version, not when you're in the first case I listed :

  >> - If you have one website, that follow best practices and renders ok on mobile

  When I write "renders ok" it may include device adaptation using or not a plateform such as yours. 

  Also, when I write "to avoid displaying the PC interface", I am thinking of the case where you have a distinct version (different files, whatever you share the initial site content or not). Interface may not be the correct word to use here.



  This topic is getting really close to the other one I suggested : "Cases where a specific mobile version is relevant". It is really hard to isolate the problems ... :-/

  This classification I tried to make in this post is a first step to debate about this topic :

  >> - If you have one website, that follow best practices and renders ok on mobile
  >> - If you build a specific interface, accessing the same contents than your ¨PC website (N.B : Need to define better "interface" and "content" here).
  >> - If you build a specific website only for mobile users, sharing some content (or not) with your PC website


  P.S : I tried your site on a i-mode device (M342i), the link on your homepage weren't even clickable.


------------------------------------------------------------------------------
  De : Rotan Hanrahan [mailto:Rotan.Hanrahan@MobileAware.com] 
  Envoyé : vendredi 5 août 2005 12:35
  À : Nicolas Combelles; public-bpwg@w3.org
  Objet : RE: Access and communication - URLs and more


  > But then, you have to identify clearly the device to avoid displaying the PC interface to a mobile and vice versa.

  No you don't. One URL is all you need for any device. Your site merely has to be aware of the device that is making the request. Whatever device you are using to access the Web, visit our home page (www.mobileaware.com) and you will see. There is no need for /mobile, or mobile.*, or /pda or any other manipulation of URLs. In our case, the URL is to our home page, and we will give you a reasonable representation of a "home page" as is appropriate to your circumstances. (We're not a content provider, so we don't put a huge amount into our web site, but our customers do for their services.)

  And we're not the only company that has this technology. Our "colleagues" in Volantis and Drutt, both participating in MWI, can demonstrate similar capabilities. And there are others. We are collectively providers of "adaptation technology", and it is generally accepted that some form of adaptation will be needed to support the Web diversity. This is why we have come together. We hope to avoid technology fragmentation. Agree a common approach. Encourage others to follow. Create the "One Web".

  My company will work with others (partners and competitors alike) to achieve this. I accept that www.* has been used as a DNS "flag" to indicate a HTTP server. It is not a guarantee, but most people know. But www.* does not currently indicate a Web site that will adapt to your device. If people insist on using DNS to signal some property of the site, then the only thing that I would possibly support is something that indicates the site will adapt, as this should cover all devices. One day, I hope that www.* will also mean that the site will adapt, but until then we will continue to work towards this goal.

  ---Rotan. (Chair DDWG, Chief Innovations Architect for MobileAware)


  -----Original Message-----
  From: Nicolas Combelles [mailto:nicolas.combelles@apocope.com]
  Sent: 05 August 2005 11:22
  To: public-bpwg@w3.org
  Subject: Access and communication - URLs and more


  Ok, let's start a new topic, specifically about access to websites.


  1. What are the different access methods to a website ?

  -> Direct user input, bookmarking, link on another website or directory or search result page, link in a mail.

  As an website editor, you have to put lots of effort on communicating your URL through these different means.


  2. How easy is it for people to access website with these methods, especially on handset device ?

  To remain simple, we can stick to the mecanisms. Either accessing requires a user click (link), or a URL input in the location bar. 
  The second being a bit more complex, and require the user to know the URL.
  This is getting more and more important on mobile, where keyboard input isn't easy. This is why mobile user mainly use the telcos mobile portals.

  Now if they try .. they will try the URL they know, most often the one of your website.

  When you need to communicate a URL to a mobile user, the best way remain to push it. Problem is compatibility with Wap push, email, and SMS with cliquable links, had again a lot of complexity to achieve it.

  In France, we have a specific portal, or rather a kiosk, called "Gallery", made by the three national telcos, where editors can register their site to be accessed by all mobile users through a search engine. Such sites have a unique code like "servicename" that users can type in the search box or in a sms sent to the short number 30130 to get access. It is getting really popular as was it's ancestor, the old french "Minitel" (which inspired the i-mode creator "Takeshi Natsuno") where you had to type "3615 servicename" .
  But well .. this is another topic.


  3. Should I keep a single URL for the mobile ?

  It depends. Most often, yes. 

  - If you have one website, that follow best practices and renders ok on mobile -> Sure.
  - If you build a specific interface, accessing the same contents than your ¨PC website -> It depends.
  - If you build a specific website only for mobile users, sharing some content (or not) with your PC website -> It depends.

  But note that a second URL MEANS a second site (like you could have your corporate site on www.company.com + your corporate blog on blog.company.com).

  It depends of your strategy :

  a) How do you want user to consider your mobile application ? A mobile "version" or a mobile "site" ?
  b) Which has the best marketing impact ? : 
     - "You can now find www.yahoo.com your mobile" 
     - "mobile.yahoo.com"

  c) Can you afford the complexification of having two URLs (time, money, and user perception) ?

  Again, most often you won't wish fragmenting your URL. 
  But then, you have to identify clearly the device to avoid displaying the PC interface to a mobile and vice versa.


  4. Which mobile-specific URL should I use ?

  This is up to you. You can add a folder or change the alias :

  www.site.com/mobile
  mobile.site.com


  You can use "mobile", but I also like "mmm" that stand for "Mobile MultiMedia". I do not recommand "wap" (first, the word "image" suffered from wap1 failure, and furthermore, wap isn't the only mobile web technology).

  I'm glad google recently replaced their www.google.com/palm URL by www.google.com/pda which is much more generic to a device family (even if hard to define) than the Palm brand (that people tend to name as a device type).

  I'm definitely not (as other already mentionned) for the new extension ".mobi".

  But don't forget that even if you choose differents URLs, you can still use a redirect on both to make sure the device goes to the correct site (thought sometime you'd wish to view the mobile site on PC, and smartphone user may want to try your PC site on their mobile).


  END.

  I may have ommitted some aspects of the questions .. but that's a good start, and anyway, this mail is getting too long.


  Regards,
  Nicolas Combelles
  Apocope