I didn’t have a phone and needed one to demo Opera Mobile and Opera Mini, so decided to get the sexy Samsung Omnia.
I took a while to get hold of; they’d all been sent back to Samsung, one operator said, because of software problems. I perservered, and eventually got one. It costs £35 a month with 600 minutes of talk, 250 texts, free landline calls, and free data (fair-use policy applies). The shop promised me free satnav, but Vodafone then told me that wasn’t the case.
It’s a nice shape; it feels robust and sturdy. The screen is nice and big, responsive to the touch and sound quality is good. But despite its excellent specs, I haven’t been able to get 100% comfortable with using it. I don’t hate it; it’s a very useful and versatile beast, but I can’t get to love it. Elliott Kember (of Carsonified) showed me what the problems were: basically, the problems are down to Windows Mobile.
I’ve never owned a Smartphone before, so Elliott put his iPhone and my Omina next to each other and we compared them. Now, I wouldn’t have an iPhone; the price, the low specs and the fact that I can’t have the browser I want rule it out for me. But it’s undeniably a much better user interface than the Omina.
For example, when entering a new contact, the iPhone switches automatically to the numeric keypad for entering a number, and to the text keypad when you enter a name. This is obviously the correct behaviour, whereas the Omnia defaults to the text keypad, meaning there’s an entirely spurious step of selecting the numeric keypad. What a waste of time.
There’s also the annoyance that when you’re speaking, the keyboard locks and if you need access to the keypad during a conversation (to select a menu item on an automated “triage” phone system, for example) you have two keystrokes to make before you enter your selection. I know that this can be changed using some options, but proper testing with real people would have resulted in better defaults.
Opera is great on the Omnia; it’s responsive and renders perfectly. But the rest of the machine doesn’t feel 100% right to me—and I’m a Windows user.
The user experience of the iPhone is very good, and applications like AirMe, which upload straight from your camera to Flickr are just the way I think software should be (although that one isn’t made by Apple, ironically). But the fact that you can’t choose a wallpaper, a ring tone, a carrier or a browser spoil it.
So there still isn’t a phone perfect for me. Perhaps I should have done as Stuart Langridge suggested and wait for a phone that can run Opera Mini on Android.
I’ve been quiet lately as I’ve been gallivanting. Last week was exhausting but amazing, as I toured with Eric and Roberto from Opera giving talks at English universities on an Opera Education university tour.
Rather than just pimp the company and bore the audience rigid, I gave 45 minute talk about why and how you should use Web Standards for any-device development, and took the audience on a lightening tour around SVG, CSS 3 and (mostly) HTML 5. (The talk needs a labs build of Opera that includes support for the video element.) Grab the talk Web Standards for the Future on the Opera Developer Network blog.
Feedback shows that we got the balance right—in fact, some people actually said they’d like to hear more corporate information! People also caught on to my personal excitement about the subject matter. I’m really excited about using Standards like SVG and CSS media queries to build the mobile web. Our figures from our Opera Mini servers for September 2008 show
Egypt now has more mobile web use than Germany
Growth rates are soaring: Libya saw 3780% growth this year
Overall, Africa experienced a usage surge of 180 percent over the past nine months
And what’s also fascinating is that across the world people want the same kinds of sites: free (as in open and uncensored) information sites like wikipedia and the BBC, search, social networking and news. There is little difference between Poland, Indonesia, America and Egypt.
Coupled with the interesting work coming out of the w3c Mobile Web for Social Development, I think there’s a really exciting potential to use standards to help bring about change for good in the world. Or you may say I’m a dreamer. But I’m not the only one. (I’m also one of the pacifists in the browser war—and declared that War is Over, too.)
Anyway, thanks to all who came to see us and went for a beer—as well as to old friends Simon Mackie, Ian Lloyd and Jon Hicks who came out for a bevvy. And even to Elliott who made me fall out of love with my Omina.
Mobile widgets
Yesterday, I visited the Smartphone Show at Earls Court to deliver a 5 minute “speed dating” presentation about Opera Widgets. (90 mins, 12 tables, people come to a table, listen for 5 minutes until a whistle blows and audience moves on to next table.)
The presentation Opera Widgets: uses, development and standards won first prize for best product pitch, as voted for a panel including representatives of Samsung, Symbian and Nokia. I’m a bit surprised, as my talk was for developers and so I’d dressed in no-name jeans and a hoodie (more Naomi Klein than Calvin Klein) and then found myself surrounded by sharp-dressers.
Here’s me getting the award. I didn’t blub.
Oslo, Indonesia
Next week, more quietness as I go to Oslo to do an internal presentation to Opera employeers “What developers think of Opera” (so please let me know what you think in the comments or by email). Then it’s off to Indonesia to talk more about Standards, the developing world, SEO and the like.
Yesterday I was writing a presentation about web accessibility to deliver at Southamption University as part of an Opera Education university tour, and decided to include an example of a site that was a business for disabled people.
The example I used was of soundsdirty.com, a website full of erotic mp3s for the visually impaired. (Previous safe-for-work write-up.)
They had movies with subtitles and audio description. They had an excellent visual design statement:
This site uses cascading style sheets for visual layout. This site uses only relative font sizes, compatible with the user specified “text size” option in visual browsers. For a detailed overview of how to change font in your browsers please visit the ‘customize site’ link (access key U)
If your browser or browsing device does not support style sheets at all, the content of each page is still readable. The site has the ability to quickly change the font and background color to a high contrast black and white page layout. This feature is recommended for partially sighted, dyslexic and color blind users.
They had the most interesting access keys I’ve ever seen:
Access key E – Erotic Stories
Access key F – XXX Films
Access key X – Sex Sounds
Access key M – Member Stories
Access key D – Doctor Erotica
And even a panic button:
The site contains a ‘Blank out link’ (access key Q). This feature jumps to a blank page and will stop all assistive technologies. This feature can be useful if you need to get off the site quickly!
And now the domain name goes to one of those stupid “this domain has been acquired for a customer” placeholders.
I really hope it hasn’t gone .. well, tits up, as it was a good and memorable example of web accessibility. And it gave me the opportunity to title a slide “sounds dirty, code’s clean”.
One of the things that have long irritated me about HTML is the restriction on what elements are allowed inside lists.
The specs for both HTML 4 and 5 allow only li for ul, ol, and only dt and dd are allowed inside dl definition lists. I’d like to expand that to allow h1…h6, section and div.
I was talking to two of Opera’s Standards reps, Anne van Kesteren and Lachlan Hunt, about this and they suggested that I make a proposal to the HTML 5 working group, with appropriate use cases.
So before I make a tit of myself by putting flawed proposal to that somewhat grumpy group, I thought I’d do what Eric Meyer did and ask developers at large what you think. Here’s my reasoning—and if you have any more use cases or objections, please let me know.
In the UK, as most (all?) other jurisdictions, laws and rules are written with numbered paragraphs. Within those lists are headings that introduce sections. The headings are not part of a list item, but group list items. Check out any of the thousands of examples at Office of Public Sector Information or the UK Statute Law Database.
<ol>… <h2>Commencement</h2>
<li> These regulations replace the Practising Certificate Regulations 1976 in relation to all practising certificates, and applications for practising certificates, for any period commencing on or after 1st November 1995.</li>
<h2>Requests for information</h2>
<li>In addition to information supplied on any prescribed form under these regulations, solicitors must supply to the Law Society such information as to their practice as solicitors as the Society shall from time to time reasonably require for the purpose of processing applications.</li>
<h2>Replacement date and conditions</h2>
<li>The replacement date for every practising certificate shall be the 31st October following the issue of the applicant's current practising certificate.</li>
<li>Every practising certificate shall specify its commencement date, its replacement date, and any conditions imposed by the Law Society</li>
…</ol>
You’ll notice that the heading "Replacement date and conditions" is not part of either of the following two items, so is not a child of either li. Instead, it groups (or introduces) them, and therefore, its semantically most appropriate location is as a child of the surrounding ol.
Another way to mark up this document is as a succession of headings and paragraphs, with each paragraph beginning with a hard-coded paragraph number, perhaps surrounded with a span that is styled with dislay:block; in order to make the number look like a list marker. This spectacularly fails the Bruce Lawson Markup Duck Test which states that if it looks like a duck, walks like a duck and quacks like a duck then it is a duck: a list of paragraphs, each beginning with a number indicating the order of the paragraphs is an ordered list, and needs to be marked up as one.
Take a more complex example, Legal Services Act 2007, paragraphs 203-206. This legislation is a long list of numbered paragraphs, interspersed with headings to group the following paragraphs into sections. Being more complex, this legislation has nested (ordered) sublists, but the same logic and basic structure holds here too:
<ol>
…
<li><h5>
The giving of notices, directions and other documents in electronic form</h5>
<ol> <li>[subparagraph 1]</li> <li>[subparagraph 2]</li> … <li>[subparagraph 8]</li> </ol>
</li>
<h4>Orders, rules etc</h4>
<li><h5>Orders, regulations and rules</h5>
… lots of subparagraphs …
</li>
<li><h5>Consultation requirements for rules</h5></li>
<li><h5>Parliamentary control of orders and regulations</h5></li>
<h4>Interpretation</h4>
…
</ol>
A counter argument is that that these whole piece of legislation is an ordered list of sections, each containing a sublist list of paragraphs within that section.. And that is an legitimate way to look at it, except that the actual numbered paragraphs would no longer have the correct paragraph numbers auto-generated, as they’d be split into sublists.
Playing with CSS counters wouldn’t help, as different lists are treated as separate entities, so numbering in one list can’t follow on from numbering in another list. To avoid the paragraph immediately below a section heading (the h4 in my code example above) going back to 1, you would have to give the li a start attribute and hard-code the paragraph number, making a mockery of the idea of automatically generating numbers in ordered lists. Even if it could be faked with CSS counters or hardcoding the start attribute, it shouldn’t be because that fails the Duck Test, too.
HTML 5 sections
For HTML 5, it would be ideal if the spec allowed the new section element to be a child of a list. This means that content could be pulled from a CMS into different pages with different heading hierarchies, and the headings would automatically be the correct level within that context. This is an idea from the XHTML 2 spec, which has an unnumbered h element:
Structured headings use the single h element, in combination with the section element to indicate the structure of the document, and the nesting of the sections indicates the importance of the heading. The heading for the section is the one that is a child of the section element.
In HTML 5 this is complicated by backwards compatiblity, so any heading element from h1…h6 can be chosen, and the headings and sections algorithm determines what “level” it actually is. (See A Preview of HTML 5 for a more readable discussion of section).
I’ve marked up the Practising Certificate example as HTML 5 and styled the various different levels of h1s using CSS so you can see a practical example of the usefulness of allowing headings and section to be children of a list.
Headings in definition lists
An example in a definition list would be similar. Here’s a real-world glossary marked up as a definition list (which is the best way to mark them up, in my opinion, although some favour tables).
A really long alphabetical glossary would be enhanced by dividing it up with headers for each letter of the alphabet, for reasons of scannability, or so an on-the-fly table of contents generator could make a linked table of contents above the glossary.
That could be done by the following (illegal code):
<h1>Glossary</h1> <dl>
<section>
<h1>A</h1>
<dt>Aardvark</dt>
<dd>Never hurt anybody</dd>
<dt>Allegro</dt>
<dd>The lower limbs of people standing side-by-side</dd>
<dd>The finest car known to man</dd>
</section>
<section>
<h1>B</h1>
<dt>Bee porn</dt>
<dd>See Christian Heilmann, Tom Hughes-Croucher</dd>
</section>
</dl>
You might say that each letter of the alphabet should have its own dl. I contend that a glossary is a single entity, not twenty-six different lists and would reply "Tish and pish, sir. You are a nincompoop, and your words are balderdash, poppycock and gobbledegook."
And I’d be right, and you’d be sorry.
Allowing div as a child of a list
While we’re talking of rules and specifications, I’d like to know why I can’t use div inside a list.
Mostly I’d like to do this so that I could properly style definition lists to look like tables.
I agree with the HTML 5 gang when they refuse a new grouping di element (presumably "definition item"), saying "This is a styling problem and should be fixed in CSS. There’s no reason to add a grouping element to HTML, as the semantics are already unambiguous."
Yes, there is no reason for a new definition grouping element; we already have a generic grouping element called div. And, yes, it’s true that it’s a problem for CSS, but with all the other stuff on the CSS Working Group’s agenda, they’re unlikely to get round to it soon.
It must be a common problem (the HTML 5 crew cite it as a "frequently asked question") and it can be easily solved using the interoperable, backwardly-compatible method I outlined above.
It also raises a philosophical question: I can understand why there are restrictions on where some elements can go (for example, it would make no semantic sense to allow a list inside an image), but why restrict where an author can put an element that has absolutely no meaning ("The div element represents nothing at all")?
Conclusion
I see the argument against over-complicating a specification, but I think that if a new spec can’t accommodate real-world examples of content then the specification is not in danger of over-complication—rather, it’s currently over-simplistic. HTML 5 has been bravely making itself backwards-compatible and thereby becoming more complicated in some areas (such as the algorithm for working out the importance of headings in sections), so slight extra complication to help developers can also help its adoption.
Thank you for reading this far, dear reader. Am I talking nonsense? Have I missed something obvious? Do tell, before the HTML 5 gang employ sarcasm or scorn at me.
Opera Software ASA is a company headquartered in Norway. Noway is a signatory to the European Economic Area Agreement, which guarantees free trade with all EU states and cooperation in such matters as consumer protection, culture, education, and information services (see http://www.eu-norway.org/about/eeaforside.htm).
Many of our users are within the United Kingdom and the European Union, and we feel that the draft guidelines (“the guidelines) potentially disadvantage them.
We support the aim of the COI to ensure inclusion by testing public authority Web sites on a range of browsers. It is also laudable that the COI requires that Web sites be made accessible to people with disabilities and across multiple operating systems.
However, we feel that there are some aspects of the browser guidelines that need re-drafting. We request that our concerns be considered and give permission for them to be quoted with attribution in any report on this consultation.
Executive summary
Opera believes that the current guidelines attempt to reinvent a wheel that has already been satisfactorily invented and refined over time by other large organizations, both public and private. Reusing their work reduces costs to taxpayers.
Also, Opera believes that the guidelines in their current form
are anti-competitive, as they perpetuate dominance in the browser market by giving the impression that alternative browser products are inferior, and those who choose to use them are not worthy of consideration,
The guidelines should recommend using Web standards and a best-practice development methodology called “progressive enhancement. This will help ensure compatibility across browsers, rather than aiming at different browsers as if they are completely separate targets.
more consistency for Web visitors and developers, and
savings on Web development costs by promoting Web standards and proven methodologies.
These benefits are also noted in the BBC’s Objectives of Web browser support, which gives the methodology by which their browser-support matrix was devised at Appendix 2.
Guidelines restrict choice
Guidelines confuse popularity with capability
Paragraph 15 says “There may be specific browsers that you choose not to fully support because they are either old or unpopular.
It is legitimate to choose not to support old browsers fully that are not capable of rendering sites made with Web standards and progressive enhancement.
However, it is wrong to decide not to support a browser purely because it is “unpopular. If it is capable of rendering the site, it should be supported.
The guidelines’ introduction states, "It is important to declare which browsers your website has been tested on. This demonstrates a clear commitment to your audience. Users will want to know whether or not your website works with their browser."
We disagree. By naming the browsers on which a Web site has been tested (simply because they are more “popular), the impression is given that browsers that were not mentioned are somehow “second class, and its users are not worthy of attention, which demonstrates a clear lack of commitment to audience needs.
It doesn’t matter how old your browser isyou can use this website. It looks different in some older browsers, and is mostly text in very old browsers (like Netscape 4, or Internet Explorer for Macintosh). But the information is the same, and so are the things you can do.
Guidelines inconvenience users
This erroneous impression of less “popular browsers as being inferior is reinforced in the sample “browser support statement in paragraph 12.
Webmasters are advised to list browsers they have tested in as “supported. The example browser support policy statement includes the message "We advise you to upgrade your browser version as far as your computer allows and if possible to one of those listed above".
There are also many reasons why a user may not be able to change their browser easily for example, they
may not be using their own computer and be on a shared computer; therefore, they are unable to change or update the browser,
may use a particular browser because of security or privacy settings,
may use a particular browser due to features that help them access and are unable to use another browser comfortably,
may not know how to change their browser.
Many users of the most “popular browser made no conscious choice to use that browser. On the other hand, we know that many Opera users choose Opera because of features such as excellent keyboard support, the built-in voice browser, intelligent zoom, and fit-to-width display, which are very useful for people with disabilities. It is unreasonable and unfair to suggest that they upgrade because a Webmaster has elected not to test in Opera.
Potentially anti-competitive
Not only does this inconvenience the user, but we strongly believe that this is anti-competitive.
The guideines help perpetuate current market shares by encouraging users of “unsupported (in reality, “untested) browsers to replace their current browser with another.
(Disclosure: The EU Commission are opening an investigation into an anti-trust complaint filed by Opera on 12 December 2007, regarding Microsoft bundling Internet Explorer in the Operating System and not implementing Web standards.)
Guidelines do not promote best practices
The guidelines are published because it is “impractical and inefficient to test in all browsers. Presumably this should be interpreted as the COI suggesting that it is not cost-effective to do so. However, it is unnecessary to do so if best-practice Web development is followed.
Best practices should be central to guidelines
The section “out of scope notes, “How to code for browser compatibility [and] Development methodologies such as graceful degradation and progressive enhancement, are out of scope.
Additionally, paragraph 40 notes “These guidelines do not advocate specific development methodologies, for example, graceful degradation or progressive enhancement. However, it is widely accepted that sites conforming to open Web standards such as XHTML and CSS are more likely to work well across a wide range of browsers. The importance of working to technical standards is highlighted in Minimum technical standards.
Opera believes that the guidelines must recommend the development methodology known as “progressive enhancement which, when based on Web standards, would reduce inconsistencies between browsers resulting in greater interoperability.
When this methodology is employed, users of the most capable browsers automatically receive the highest quality user experience, while users of less capable browsers will receive content and be able to access basic functionality. Therefore, no-one will be “locked out", whereas being "locked out" is much more likely if you choose consciously to test only in/support specific browsers.
Guidelines erroneously treat Web as a visual medium
The guidelines treat the Web as if it were a visual medium such as print, in which designers specify pixel-perfect layout and can rely on that being delivered to the consumer.
This is not true and is inappropriate for public-service websites, where the emphasis is on content rather than aesthetics.
Paragraph 41 says, “A browser is semi-supported if the content and navigation works but the website does not display as intended.
It is incorrect to judge a Web site on whether it displays “as intended. A Webmaster cannot mark a browser “down as semi-supported because it does not have curved borders, opacity, or the same fonts as those on a designer’s machine.
By emphasizing “intention, the guidelines legitimize preservation of design as a goal. In the past, this has led many bad design decisions such as fonts being expressed in pixel sizes which cannot be resized in Internet Explorer, for example.
The Web site should be judged on whether the recipient can use it in a format that (s)he wishes. If, for example, a browser mis-renders a site built with Web standards, such that content is obscured or is illegible, then that browser is unsupported.
If a browser renders the content as legible, the navigation usable and functionality operable, then that browser is fully supported in the context of a public-service site.
Best practices lead to cost-savings
Recommending best practices whereby developers code to internationally-agreed standards rather than to circumvent the quirks of today’s market leaders leads to cost savings throughout the life-cycle of a Web site:
It is more cost-effective to build right than to correct during testing, so explicitly advocating progressive enhancement results in more efficient development and Web sites being quicker to market.
Reducing inconsistencies through smarter development ensures that the “testing phase is shorter and, in the case of static pages of content, it should be possible to reduce testing to a quicker “verification stage that quickly checks across a range of browsers that there are no significant inconsistencies.
Once deployed, Web sites built using valid, semantic (X)HTML and CSS are more maintainable because they are in accordance with international standards.
Guidelines are too fragmented
The guidelines mention design methodology and minimum technical standards in paragraph 40, but it is a leap of faith to assume that everyone else will read the second document.
The guidelines are written “for all website managers, web developers and web testers delivering public sector websites, so we recommend that all the guidance relevant to these groups be amalgamated or developers will naturally assume this supersedes all other guidance and start developing to browsers.
Additionally, the “Minimum Technical Standards document is dated May 2002 and is obsolete; it mentions CSS 2 as the latest version, allows HTML tables for layout, and does not mention Scalable Vector Graphics (SVG).
Opera recommends modernizing this document and incorporating the updated guidelines into a comprehensive document aimed at the target audiences named on the cover.
Guidelines do not address mobile and other devices
Paragraph 39 notes that Guidance on support for mobile platforms will be the subject of future guidance. Other devices are described are similarly “out of scope. (Paragraph 37 also notes, “Guidance on support for mobile platforms will be the subject of future guidance; we assume this is an editorial error.)
This further fragments the guidelines, as readers will have another set of guidelines to check.
Different guidelines are unnecessary. Recommending a progressive enhancement methodology ensures that Web pages work across all browsers and devices.
Guidelines ignore plug-ins which are independent of browsers
The guidelines ignore the subject of browser plug-ins, such as those that allow readers to access PDF, MP3, video, and Flash content. These plug into a browser but are independent of it. Therefore, a group of users running the same version of a browser may have different versions of plug-ins and receive markedly different experiences.
For example, a visitor running Opera 9.5 with Flash Player 6 would not be able to take advantage of any accessibility features built into a Flash movie, while a visitor running Opera 8 with Flash Player 7 would be able to use those accessibility features, because the plug-in has a higher specification, even though the browser is less capable.
The guidelines should address plug-ins, independently from browsers.
Opera also suggests that the guidelines for Web developers require the use of open standards wherever possible, while allowing content that requires plug-ins as a secondary delivery method.
Guidelines should recommend testing by disabled users
Opera welcomes the guidelines’ inclusion of a requirement that Web sites be tested with assistive technologies.
However, the guidelines currently legitimize a sighted developer using a trial version of a screenreader and comparing the synthesized speech with the words on a screen, which is inadequate testing; a sighted user cannot have the same experience or knowledge of the tool as a real user.
“All organizations, regardless of size, should ensure that those testing the website are different from those developing it.
“Website commissioners should conduct user testing with disabled participants to ensure that their websites are accessible and usable by disabled people
User testing should include users from a range of disabilities and preferences, including a mix of beginners and experienced web users using a range of assistive technologies.
Inadequate definitions/ ambiguities
Paragraph 46 suggests testing “ability to bookmark as part of testing a Web site. That is a browser feature, not a developer-authored feature and thus out-of-scope.
Why are Rich Internet Applications separated out? The requirement for sites to work with scripting turned off, etc., is not solely related to RIAs.
Too many trademarks used in examples
We would prefer it if more than one trademark were used as illustrative examples, or none at all, as currently the guidelines erroneously give the impression that only one browser exhibits the qualities being discussed.
For example, we would prefer it if paragraph 50 were redrafted to read, “Certain browsers (e.g., Firefox and Opera) are developed using cross-platform technology (e.g., Java) and, therefore, behave similarly on different operating systems, or “Certain browsers are developed using cross-platform technology ….
Contact details
These comments were written by Bruce Lawson, a Web Evangelist representing Opera Software ASA. Bruce may be contacted via brucel@opera.com for any clarification of these comments.
The usually tranquil haven that is Chateau Bruce is disrupted. Covetousness stalks the halls, ballrooms and paddocks of my humble abode.
My dear wife and daughter have just this week bought new Nintendo DS Lites, after watching young James play his birthday DS with envy.
And all because I walked downstairs after finishing work yesterday and, enroute to the teapot, said “Have you seen they’ve announced the new DS? It’s got two cameras, a bigger screen, it’s thinner and you can play funny games with faces and voices.”
At my casual conversation opener, all three Lawsons simultaneously paused whatever hypnotic beeping warfare they were engaged in.
“Ohh!!! And we’ve only just bought these! Why didn’t you tell us it was coming? It’s not fair!!“. And that was just the wife.
When I told them that I might get a free DSi from work for testing, because a “genius” implementation of the customised Opera browser (see video: third slide down) is available free from the DSi online store, I got death stares worthy of Paddington Bear.
for some reason, WordPress has decided to lose all comments on this blog.
It happened after my web host restarted the database server because of one of those occasional “error establishing a database connnection” errors that WordPress blogs seem to randomly spew out.
