Today Adobe released a preview of their new WYSIWYG website creator, Muse. Shortly after, I had a good old moan about it on Twitter. Not, as you may think, because I feel threatened by website creation being made easy — it’s been easy for ages, but ‘easy’ doesn’t always mean ‘good’ — but because it gets a few fundamental things badly wrong.
My code purist side rejected it because the markup it outputs is horrendous; if you don’t believe me, take a look at the code for one of their example sites, ‘Lucid Synergy’. My educator side rejected it because it teaches you nothing about how a web page is made; I learned to code by using Microsoft FrontPage many (many) years ago, and understood HTML by editing the source of the document and tweaking it until I got it the way I wanted — but Muse has no code view, so this is made very difficult.
But the real problem with Adobe Muse is deeper than that: it’s that all semantic sense is completely removed from the page. There are no headings, no lists, all text is in p elements, inline styles are applied with span rather than em/i/b, etc; this gives no structure, no meaning, no aboutness to your page, which at the very least means penalties for SEO.
And worse still is that there’s no document flow; all the elements you add to the page are positioned relatively to their parent and follow no particular order, which is pretty bad for search engine spiders (and hence your SEO), but absolutely terrible for visitors using assistive technology.
It’s the product of a company that cares only about appearance, and nothing for content. As @paulrobertlloyd said on Twitter:
It’s not that the code Adobe Muse generates is ugly, it’s that it’s meaningless.
The issue with the lack of semantic elements is not insurmountable, it just needs some work by Adobe before the final release. The lack of document flow and content order is more serious, however, and will need a complete rethink; I hope that this happens.
As I get ready to kick off a couple of personal web projects, I’ve been reading Enric Jardí‘s book, Twenty two tips on typography*, a primer on what works and what doesn’t in typography.
Although Jardí mainly works on type for print, most of the rules also apply to type for the web. In this article I’m going to highlight five of his tips which are useful in deciding upon the right type for a project.
To great fanfare, The Queen, in the company of Sir Tim Berners-Lee, unveiled the new British Monarchy website today. Unfortunately, what they unveiled was a real dog’s dinner.
Royal.gov.uk highlights the worst elements of the practice of web development; on only the second page I visited it became obvious that the site hasn’t been tested on any browser other than Internet Explorer, and a peek at the source code left me shocked.
I’ve just finished reading John Allsopp’s book ‘Microformats: empowering your markup for Web 2.0′, and thought it deserved a review here — marked up, of course, with hReview. I was given a free copy at the recent Microformats vEvent, but hope that hasn’t coloured my review at all. Markup for the review was generated by the hReview creator (and slightly modified by myself).
As promised, slightly more detailed notes on the sessions at FoWD (further links to presentations to follow). In chronological order:
I missed the beginning of this, but it seemed to be pretty sage, if not rather commonsense, advice (don’t just use websites for web design inspiration), as well as some notes on current trends and tips on future ones; soft colours, more use of horizontal space, more video.
Set up as a confrontation, but in fact both speakers were at pains to point out that both should be thought of together. Andy Clarke adds: don’t be afraid to fail, we learn from our mistakes.
Yesterday I attended the Future Of Web Design London event in Kensington (along with my lovely wife). Unfortunately I’ve been suffering from some stinking virus for the past couple of days, which left me uncomfortable, occasionally in pain, and irritated. Please bear in mind that this may have coloured my perception of the event somewhat; also, please accept my apologies if you were at the event and start to suffer the same symptoms in a few days.
I’ll write short reviews of the individual sessions at a later date, but my general opinion is that it was just OK; it dealt more in current design trends than future, almost all of which you probably already know if you keep up to date with sites like A List Apart or some of the better blogs. Although that’s not to say it was a complete waste of time; few of the speakers were less than interesting, and there are always new techniques to learn or existing techniques to reinforce.
Some of the speakers suffered from not having worked (or, at least, not for a long time) in a regular agency position (if I may coin a phrase, coal-face web development), and their advice was therefore useful on a theoretical basis only. Sure, it would be great if we could make mistakes in public and make constant revisions to our websites, but who pays for that? The client almost certainly won’t. We think ourselves lucky to have some clients who are savvy enough to make annual revisions to their sites! And while I’d love to just “get better clients”, that’s just not how the real world works for those of us who don’t work at start-ups or own our own agencies.
In summary, then, compared to last year’s @media, which I found genuinely inspiring, this was ‘only’ interesting. I’ll give careful consideration as to whether or not I attend again next year.
For no particular reason other than idle curiosity, I made a demo of a broken neon sign, using CSS Animations (you’ll need Firefox 5, Safari or Chrome to see it). It doesn’t degrade well at the moment, the root cause of which is down to what I think is a bug in Firefox’s implementation — I’ll need to confirm that.
One quick learning from making this: it would be really useful to have CSS Mixins when using a lot of repetitive keyframes, as I do in this animation. The W3C seem to be quite against them, however.
[#] 3 Comments