- From: Tammy <taylortk@verizon.net>
- Date: Tue, 02 Aug 2005 00:36:40 -0400
- To: Paul Walsh <paulwalsh@segalamtest.com>
- Cc: 'Tim Moss' <Tim@bango.com>, "'Holley Kevin (Centre)'" <Kevin.Holley@O2.com>, 'Daniel Barclay' <daniel@fgm.com>, 'Barbara Ballard' <barbara@littlespringsdesign.com>, public-bpwg@w3.org
I'm not sure that having a different displays for different devices requires maintaining 2 or more versions of content. When developing Web sites areas of a Web site grid can be categorized and organized by the type of information that goes into each area. These are some common areas: 1) Heading/banner (which generally contains the most important information about the Web site as a whole) with a logo or marketing slogan. 2) Main navigation 3) Sub navigation 4) Main content (which contains the important information as it relates to the page's main purpose) 5) Secondary content (additional area for information that may be related to the pages content but not main content). 6) Footer area (dates, web master information, copyright, disclaimers etc.). Secondary content might be something that fills up the space on a larger screen but is too much for a smaller screen and not necessary for the page's main purpose. Main navigation content is generally the same on every page and every device/screen size. If the content is separate from the display then the content could be considered 'objects' and these objects of content can be placed even using something as simple as a text file and a server side include (SSI). I did this with a Web site and developed so that only the pages main content was on the page everything else that is reused on other pages (site structure, navigation, sub navigation, section headings, secondary content, footers) are all called in through SSI. It really makes for short and clean source code and makes updating pages easier: there is less code to wade through. This can be taken one step further by making the main content an object as well. Content objects are called in as needed or when requested (based on user/device input). The amount of display should be controlled via content layouts (different set-ups for different devices) using templates and CSS. This way the content has only 1 version but different layouts/styles for various ranges of displays. Tamara Taylor Paul Walsh wrote: > Again my comments can be found below. You’ve been a busy bee Tim, > great to get such debate going :) > >> -----Original Message----- > >> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On > >> Behalf Of Tim Moss > >> Sent: 31 July 2005 21:27 > >> To: Holley Kevin (Centre); Daniel Barclay; Barbara Ballard > >> Cc: public-bpwg@w3.org > >> Subject: RE: Best Practices document - not best practices > >> > >> > >> Well those who are believers in the strict interpretation of the "one > >> web" goal would say that you shouldn't be able to tell the difference > >> at all. > >> > >> However, I think that is rather idealistic, and following it too > >> strictly could end up making the user experience worse in some cases > >> rather than better. > > [PW] I am a believer in the strict interpretation of the ‘one web’ but > with an appreciation for how mobile devices work and their limitations > ‘today’. I am completely independent to the two sides of the coin; > Web/Mobile as it appears to be. My belief is to encourage the ‘one > web’ where a site is created once and rendered according to the device > and location accessing it. This is not stating that a mobile > experience has to be identical to that of a desktop PC. It is stating > that a mobile experience should not be created separately unless it’s > technically impossible to deliver it once, or where a specific mobile > experience is required. To manage this, we will need to define what > the latter means. I think the latter is the only part that should be > debated – not ‘the one web’ *_concept_*, as this is clearly the goal > of the W3C and has been for some time. > >> > >> The Google site works well on a mobile and PC web browser, by detecting > >> the type of device you are on and redirecting you (if necessary) to a > >> different URL, www.google.com/wml (on my phone anyway) that then > >> presents a different version of the content, specific to your device. > >> This is fine, and hats off to Google for taking mobile users seriously. > > [PW] Thanks for providing a great example that proves my point. Google > could have created ‘one web’ that rendered on a mobile just as it does > on a PC. There are no limitations in design requirements are there are > no reasons why you would need a specific mobile experience. Now you > have a potential issue with version control, thereby discriminating > against one party. Added to this, you have the additional cost of > maintaining two versions of the same content. Why would you want to > create two versions if you could create just one?! > >> > >> A purist might say this breaks the "one web" principle. If you shared > >> bookmarks between your PC and your phone, and try to access > >> http://www.google.com/wml with your PC browser, then you won't get so > >> far.*//* > > [PW] You don’t have to be a purist to see it breaks the W3C principle > – you do however; need to understand this principle before you can > progress with reviewing the standards and best practises that support > it or you (figuratively speaking!) will end up spending all your time > debating everything. > >> > >> Its not a huge leap from the process that happens above to redirecting > >> the mobile user to http://www.google.mobi (which thankfully doesn't yet > >> exist) as this would be an example of breaking the web. > > [PW] What’s the difference because I don’t see one? As far I as can > see, two different user experiences have been created when it wasn’t > necessary. I don’t agree with .mobi because it splits the Web into two > by encouraging the creation of a mobile specific experience (full > stop), but you don’t mind this as long as it doesn’t have the specific > .mobi domain – what’s the difference as I see this as a contradiction > in terms? Without getting into the whole .mobi debate though. Please > note that I expressed my personal opinion only. > >> > >> > >> I may be somewhat biased ;-) > >> but a better, or at least another example of a well behaved site is: > > [PW] Yes I agree, you are biased. I think everyone who is biased needs > to change hats to ensure we end up with a best practise that doesn’t > sway in their favour. Independence is important. > >> > >> http://wap.bango.net > >> > >> Once there, if you choose "Search Directory" you can find a variety of > >> mobile content. > >> Whether you visit this site on your phone, or on your PC browser, you > >> will receive exactly the same experience. (Please do try this!) > >> > >> > >> Well ... My last assertion isn't quite true, your experience may vary > >> depending on your network operator, but that is by design. > >> > >> Is this the best experience though? > >> > >> > >> If you visit > >> > >> http://www.bango.net > >> > >> on your phone, you will (hopefully) have the same experience as you did > >> above. > >> > >> If you visit this second URL on a PC browser, you will be deliberately > >> redirected, (whether rightly or wrongly according to the theory), to an > >> experience that should make the process of finding mobile content on > >> your PC much easier and more enjoyable. > >> > >> > >> I think this illustrates a key question, that I'm not sure has been > >> discussed much so far: > >> > >> By automatically adapting the content based on the device accessing the > >> site, are we in fact restricting the user's choice? > >> > >> I believe that one of the Best Practices should be to include on all > >> sites a standard and simple way to allow the user to decide whether they > >> want to see the 'fully blown' version of the content even if they are > >> viewing it on a mobile device, or vice versa, to be able to view the > >> summarised/abridged mobile version of the content on their PC browser. > >> > >> > >> > >> Take for example the MWI 'homepage' here: > >> http://www.w3.org/2005/MWI/ > >> (I've picked this page purely as an example of a relatively simple web > >> page in terms of design/layout etc and the amount of information on it - > >> I'm not saying anything about the quality of it in the context of this > >> discussion!) > >> > >> > >> That page (at he time of writing) contains roughly 5500 characters of > >> text > >> which equates to about 3 'screens' in my PC browser. As such it is a > >> nice easy web page to read. > >> > >> On my phone it works quite well too as the browser will display about 10 > >> lines of text with about 25 characters on each line. The logos at the > >> top work well, the headings come out in different, coloured fonts. The > >> 'News' section comes out in a box with a shaded background and the text > >> is all in one long narrow column so I can just scroll down to read it > >> all. > > */[/*PW] I have volunteered to host a focus group to see what the user > preferences really are and this is now an action item. If anyone on > this list is interested in taking part, please let me know and I’ll > include you in a separate group. > >> I do however have to scroll through about 20 or so screens to do so. > >> > >> > >> If I looked at this page on my first WAP phone (which had a monochrome > >> display that showed 3 lines of 15 characters) then it's a different > >> story. > > [PW] We need to have a cut off point and look to the future whilst > embracing current technology and its limitations. The goal is best > practise for _future_ content authoring. Therefore taking the ‘first’ > WAP device probably isn’t ideal. As Vendors will tell you, new devices > will be more Web savvy when they see the requirements come in so we > might have an entirely different device type in a year from now. We > don’t want to cut off half the world by base lining new devices > though, but we also don’t want to encourage content authoring that > will render on a very old model. Look to the future, not just what is > available today. > >> The images wont work, the headings are indistinguishable from the rest > >> of the text, and to read the whole page I need to scroll through way too > >> many screens. > >> > >> In this situation I'd much rather have the choice of seeing a summary. > >> If there was a link near the top that said 'read the short version for > >> mobile phones' that linked to an abridged version of the text, then I > >> may well persevere and read the page, and although I'd clearly lose some > >> of the fine detail, that is my choice. > >> > >> On the other hand, if I had no other way of accessing the page, and > >> needed to know every detail, then I could also scroll rather painfully > >> through 100 or so screens of text and achieve my goal. > >> > >> > >> The point I'm trying to make is that it isn't always best to try and > >> display exactly the same content on every device. > > [PW] Nobody is trying to say this, as per my previous messages. > >> > >> Content adaptation could make the experience better for the user in many > >> cases, but a good 'best practice' would be a standardised way of > >> allowing the user to override the adaptation decisions made > >> automatically for them, if they so wish. > > [PW] Adaptation is last resort where it’s a necessity. I’m writing > what ‘one web’ means for the MWI (for review) so I will take into > consideration, what it doesn’t mean as this appears to be more confusing. > >> > >> > >> > >> > >> > >> > >> > >> Tim Moss > >> CTO > >> Bango > >> > >> e: tim@bango.com > >> m: +44 78 8779 4032 > >> t: +44 12 2347 2823 > >> w: http://www.bango.com > >> > >> > >> Mobile Content World 2005 > >> ****************************************************************** > >> "Come and see us on stand 14 at MCW 2005 > >> Olympia Conference Centre, London, UK > >> 13th - 15th September 2005" > >> www.mobilecontentworld.biz > >> > >> > >> > >> > >> > >> > >> > -----Original Message----- > >> > From: public-bpwg-request@w3.org > >> > [mailto:public-bpwg-request@w3.org] On Behalf Of Holley Kevin (Centre) > >> > Sent: 20 July 2005 21:24 > >> > To: Daniel Barclay; Barbara Ballard > >> > Cc: public-bpwg@w3.org > >> > Subject: RE: Best Practices document - not best practices > >> > > >> > > >> > Could I ask how we tell the difference between "mobile web" > >> > and "regular web" ? > >> > > >> > Personally I use a mobile device to view "web" pages. In > >> > many cases I can read what is there irrespective of whether > >> > the target is "mainstream web" or "mobile web". > >> > > >> > Witness http://www.google.com/ > >> > > >> > This website displays very well on mobile devices and > >> > desktop-based browsers. > >> > > >> > Regards, > >> > > >> > Kevin > >> > > >> > -----Original Message----- > >> > > >> > ===================================================== > >> > This electronic message contains information from O2 which > >> > may be privileged or confidential. The information is > >> > intended to be for the use of the individual(s) or entity > >> > named above. If you are not the intended recipient be aware > >> > that any disclosure, copying distribution or use of the > >> > contents of this information is prohibited. If you have > >> > received this electronic message in error, please notify us > >> > by telephone or email (to the numbers or address above) immediately. > >> > ===================================================== > >> > > >> > From: public-bpwg-request@w3.org > >> > [mailto:public-bpwg-request@w3.org] On Behalf Of Daniel Barclay > >> > Sent: 20 July 2005 17:26 > >> > To: Barbara Ballard > >> > Cc: public-bpwg@w3.org > >> > Subject: Re: Best Practices document - not best practices > >> > > >> > > >> > > >> > Barbara Ballard wrote: > >> > >> I think you missed my point: It's a bit contradictory > >> > >> (hypocritical?) for a page about best practices for the > >> > mobile web to > >> > > >> > >> not follow best practices for the regular web. > >> > > > >> > > > >> > > If the document is written for mobile web, then best > >> > practices for the > >> > > regular web are irrelevant. > >> > > >> > The document _about_ the mobile web is _presented_ on the regular web. > >> > > >> > Although good practices for the regular web may be irrelevent > >> > to the _content_ of the document, they are certainly relevant > >> > to the _presentation_ of the document. > >> > > >> > Not bothering to understand and follow good practices for the > >> > regular web in the presentation of that document certainly > >> > does not instill confidence in the content. > >> > > >> > > >> > > In fact, best practices for the regular > >> > > web can greatly interfere with the experience on the mobile web. > >> > > >> > Actually, I wouldn't be surprised if you're referring to > >> > common practices that I'd argue aren't good practices (e.g., > >> > pages or text documents that have widths tied to fixed-width > >> > elements). > >> > > >> > > >> > Daniel > >> > > >> > > >> > > >> > > >> > > >> > > >> > >
Received on Tuesday, 2 August 2005 04:38:23 UTC