Topic: Standards

An Event Apart: Wrap-Up

Brian Dillard, Friday, August 31, 2007 @ 5:30 am

The dust has cleared from An Event Apart Chicago 2007. Now that I've gotten the basic reportage out of the way (here and here), on to the editorial page.

Three things I loved

• The wide range of topics: Despite increasing specialization in the web-development field, jacks of all trades still dominate our industry. An Event Apart offered sessions by and for designers, information architects, writers and developers alike. The most interesting sessions were often the ones that didn't cover my own specialties. Dan Cederhom and Jason Santa Maria both tackled visual design. There was little overlap between their presentations, yet each offered up practical device for folks who have to wing it with graphical design without much formal training. Similar cross-functional advice dominated the agenda.
• The skepticism about rules: Presenter after presenter - most especially Liz Danzico - prioritized guidelines over rules, research over dogma, and attention to one's own audience over one-size-fits-all solutions. One thing that usually distinguishes a great developer, or at least a mature one, is the ability to juggle a host of competing concerns without getting lost in the weeds. Accessibility vs. Ajax, beauty vs. usability, power users vs. Great Aunt Tilly - everything is a tradeoff. If there was on overriding message to An Event Apart, it was that we have to think deeply and often about our audience, our business and our objectives and make informed decisions.
• The focus on end users: It should surprise nobody that the ALA folks are usability nerds, standards geeks and champions of the end user. But it was inspiring to see how the speakers translated that well-worn agenda into series of discrete, actionable tips for everyday developers. As with any complex human endeavor, web development is all about picking your battles. With a potentially limitless number of improvements that could be made to any site or application, it's easy to feel overwhelmed. Most speakers showed how simple steps could provide incremental improvements in usability, accessibility, compatibility and profitability - all without starting over at the ground level.

Three things I didn't love so much

• The absence of concurrent sessions: Packing all 500 attendees into one room for the same 12 sessions (picture here) allowed ample cross-pollination. I'm an RIA developer, but I got the most out of the design, IA and BI sessions. Nevertheless, I longed for the ability to choose from multiple sessions, split off from my colleagues, and come back together during breaks to compare notes. It's not that any of the sessions were completely worthless. It's just that most were designed for intermediate skill levels in the same core technologies. I really didn't need to spend 15 minutes having xmlHttpRequest and getElementByID explained to me. It would have been great if some content had been pitched to masters as well as journeymen. The only way to make that work is through careful scheduling of multiple concurrent sessions.
• The dearth of programming content: A List Apart calls itself a site "for people who make websites," but not for people who make webapps. The broad range of topics very rarely extended to the programming realm. Only one session directly tackled JavaScript, and it was at an extremely elementary level. There was nothing on Java, Ruby, Python or .Net, let alone RIAs, widgets, mash-ups, Flex, Silverlight, GWT or JavaScript libraries. I know, I know, plenty of conferences already cater to those crowds. But as a programmer, I felt shortchanged. Again, concurrent sessions could have solved this, but I'm not sure programming - client- or server-side - will ever be on the ALA crowd's agenda.
• The lack of schmooze time: The schedule included some after-hours social events and a 90-minute lunch break each day, but I talked to lots of attendees who felt like they didn't get enough time to chat with other attendees. Other than a lonely bulletin board - and a social-networking site opened a few weeks ahead of time - there weren't a lot of structured opportunities to connect job-seekers and recruiters or peers from separate companies. Part of the problem was probably the cramped accommodations. When folks had breaks, they were too busy stretching their legs to schmooze. Still, I would have loved to see breakaway sessions aligned by job or industry categories.

Conclusions

For "people who make web sites," An Event Apart was probably a fantastic chance to hear practical advice and smart prognostication from industry leaders. For people who write client-side webapp code, it was a very good round-up of philosophies and techniques that too often get lost amidst the technical details. For pure software engineers, it probably would have been a waste of time and money.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

An Event Apart Chicago: Day 2

Brian Dillard, Wednesday, August 29, 2007 @ 9:03 am

Tuesday saw the conclusion of An Event Apart Chicago 2007, the two-day web-development conference from the folks at A List Apart. Here's my sequel to yesterday's day-one overview. I'll be back Friday with analysis and afterthoughts.

Jeremy Keith, author of "Bulletproof Ajax" and "DOM Scripting," led the day. His topic? "Be Pure. Be Vigilant. Behave," wherein he outlined the concepts behind "Hijax," the application of progressive enhancement to Ajax functionality. A staunch proponent of unobtrusive JavaScript, Keith warned against throwing web standards out the door when developing Ajax functionality. His examples demonstrated how to separate behavior from content and presentation by abandoning such outmoded techniques as the javascript: URL pseudo-protocol. His most extensive example showed how to code a graphical widget for the assignment of star ratings so that it would degrade gracefully into a standard HTML select box in less capable browsers. After discussing the difficulty of making XHR functionality play nicely with bookmarks and the back button, Keith acknowledged that his parting message - when in doubt, leave XHR out - was a bit of a copout for the author of an Ajax manual.

Next up was Luke Wroblewski, a Yahoo product designer whose resume includes work on the original Mosaic web browser. Wroblewski covered "Best Practices for Form Design" using exhaustive research from his forthcoming book on the subject. In case study after case study, he demonstrated how simple choices in the design and deployment of HTML forms - from the widths and alignment of inputs and labels to the placement and visual differentiation of cancel and submit buttons - can cut the time it takes to complete them in half. Wroblewski's most persuasive argument, however, was conceptual rather than technical. He made a powerful case that because forms are barriers between users and the things they want to do - buy your product, join your site or begin creating content - you should make them as easy to get through as possible. This central thesis added considerable weight to his many practical how-tos.

Accessibility advocate Derek Featherstone closed off the morning with "Accessibility: Lost in Translation." Featherstone looked at how markup choices can make a site transparent to assistive devices - or render it totally opaque. Using real-world examples from Amazon and other sites, he demonstrated how screen-reading software actually parses markup. His live examples proved that the lack of semantic markup and the absence of ostensibly optional HTML attributes can render a site worthless for disabled users. Featherstone then went beyond the basics, explaining how source order - the sequence in which nodes appear in your markup - can be used to enhance accessibility. By placing your central content first, then positioning chrome above it with CSS and providing jump navigation to skip past inessential modules, you can achieve the presentation you want for typical users without shortchanging disabled ones. In another example, Featherstone examined the ways in which meaning can be encoded in the color and position of elements on the page - and how to replicate that meta-data in a way that disabled users can understand. As with many of the other speakers, Featherstone's examples argued persuasively for the continuing relevance of web standards.

After lunch, CSS expert Eric Meyer again took the stage, this time to explore "The State of CSS in an IE7 World." Using the recent release of Microsoft Internet Explorer 7 as a springboard, Meyer illustrated the concepts that have governed the changing of the browser guard for more than a decade. His overall premise was that developers need to use their own server logs to gauge when support for an older browser can safely be dropped for their site. For most of us, IE6 isn't going away anytime soon, so we need to get creative if we want to harness advanced functionality. To that end, Meyer delved deeply into the details of IE7 techniques, filters and hacks. He praised the browser for the strides it makes over IE6's CSS engine in such areas as child selectors, adjacent sibling selectors and attribute selectors. His real-world examples demonstrated how such functionality adds power and elegance to our code. To cope with IE6's continuing market share, Meyer advocated the use of Dean Edwards's IE7 compatibility script, a JavaScript library that adds IE7 capabilities to older versions of the browser. The take-home message was that older browsers may take a long time to die out, but creative programming techniques can harness the future of CSS now.

The final two sessions for AEA Chicago 2007 were a little offbeat, which was a relief after 10 technical sessions in the previous 32 hours. In the highly anecdotal "Selling Design," ALA publisher Jeffrey Zeldman used stories from his own long career to illustrate best practices for handling difficult clients. His thesis was that collaborative work requires us to deal with a wide range of other people, so we should hone our ability to influence our collaborators - and pick good clients to begin with. Agency owner Jim Coudal closed things off wittily with "Dealing With the Both of You," a slide-free presentation about the crossover between personal projects and professional work-for-hire. Coudal assembled a number of satirical short films to drive home his point: Because most web developers are curious and easily bored, we should strive to marry passion with professionalism whether our clients are external or ourselves.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

CSS considered harmful by Ajaxian commentators?

Brian Dillard, Wednesday, August 22, 2007 @ 5:23 am

There's a super-entertaining comment thread/flamewar going down at Ajaxian in response to Dion Almaer's recent editorial on The Future of CSS and the end of 3.0. Almaer has lots of interesting and perceptive things to say about the maddeningly erratic way in which new standards make their way into general use. But the vast majority of commentators jumped at the chance to sound off on some of his minor points:

CSS is great for simple web style. CSS is awful for layout. Rich Ajax apps need layout. You spend the majority of your time trying to get CSS working correctly!

Of those four assertations, there's not a single one I can fully endorse. IMHO, current implementations of CSS are _pretty good_ for simple web style, but they're not great. (See the comments for many examples: rounded corners, varied fonts, etc.) They're not great for layout, either, but if you take the time to learn the tricks - and account for spotty browser implementations - then you can develop attractive, robust and usable UIs using CSS. As for whether rich Ajax apps need layout, well, yes. But what kind of layout is open to considerable interpretation. Just because the first few generations of web designers kept trying to apply the same old print paradigms to the browser doesn't mean it was right. The same goes for the current wave Ajax frameworks and the desktop-app layout paradigms some of them attempt to implement.

The assertation that bothers me the most, though, is the one about the time it takes to get CSS working properly. As with any code executed in the browser, CSS is subject to the quirks and peccidillos of browser vendors, operating systems and ever-mutating standards. Still, once you account for the major differences in execution environment, it's not that hard to come up with a single global stylesheet that can zero out built-in styles and browser quirks to offers a more or less blank canvas for cross-browser CSS development. CSS authors may not release their design frameworks under open-source licences the way JavaScript authors do. But that doesn't mean they don't exist. Just peek under the hood at a big, forward-thinking consumer webapp or pick up a Jeffrey Zeldman book.

Regardless of what _I_ think, the thread at Ajaxian provides an interesting vox populi. As can be expected, comments range from wholehearted endorsements of Almaer's position to finger-wagging about the importance of web standards to chest-puffing from people who've mastered the tricky art of CSS layout and don't have much sympathy for those who haven't. I'm fascinated by the way participants in these conversations let their personal investment in a certain skill set lead them to make sweeping generalizations about entire swaths of the software-engineering world. Just because you know how to make a site look a certain way using tables, or floats, or XSLT, doesn't mean that that's the only way, or that the Internet won't eventually cough up a much better way than any of the above.

The fact is, any programming language or development framework can be improved, and there's lots to both love and hate about the CSS specs and the various imperfect implementations of them. It's _so_ far from the all-or-nothing proposition that many of the commentators would have you believe.

Dealing with client-side technology is frustrating for anybody who's used to having complete control over their execution environment, or a stable platform at all. The reason the pace of change is so glacial on the client side is that standards take time to develop; vendors take time to implement them; and a variety of market forces contribute to how well and how quickly they're implemented. Nobody said the Open Web was easy, but it's vastly preferable a host of closed-off, proprietary formats controlled by individual vendors and immune to grassroots innovation.

Any developer who's lived through successive generations of client-side technology knows that things have only gotten better with time. It's hard to imagine that standards won't continue to improve, no matter how painfully slow the process.

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

The Effects of Unbreaking IE

Dietrich Kappe, Wednesday, September 20, 2006 @ 1:00 pm

I was listening to Audible Ajax Episode 18 -- the interview with the IE7 team -- yesterday, and about halfway into the podcast, I heard something that had me fall out of my chair with laughter. One of the guys (sorry, they all look alike on a podcast) mentioned that if you surf the web for a prolonged period of time with IE7, you begin to see little anomalies in presentation, functionality, etc. If you dig a little deeper, you see that people are depending on IE6 quirks and bugs to get their sites to render and perform correctly. Aside from the hillarity of everyone having to unquirk their sites and applications when IE7 comes out in general release, it is an object lesson in how Microsoft can embrace and extend a set of standards even if they don't mean to.

Hopefully the IE releases will be coming faster now, and bugs won't have a chance to be enshrined as standards anymore.

Technorati : ie7, quirks, standards

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

Open AJAX Initiative

Dietrich Kappe, Monday, June 12, 2006 @ 9:00 am

Right now AJAX is in its Wild West phase. Every day brings a new framework, every week a new technique. This intellectual ferment is great for innovation, but it makes commercial product managers nervous. It is risky, adopting new and changing technologies, and the penalties for adopting the wrong one can be severe.

At some point, however, the innovation slows down and standards emerge. It becomes safe for the Fortune 500 to venture into the water -- you just don't want to have standards take over too soon and stifle innovation. But with the invention/adoption cycle getting so much tighter, some product managers will adopt AJAX in the face of uncertainty. Either they go the perceived safe route and go with MS Atlas, or they look to an equivalent security blanket on the non-Microsoft side.

Enter the Open AJAX Initiative. From the release (emphasis added):

The initial supporting members of the new initiative -- dubbed Open
Ajax -- include BEA, Borland, the Dojo Foundation, Eclipse Foundation,
Google, IBM, Laszlo Systems, Mozilla Corporation, Novell, Openwave
Systems, Oracle, Red Hat, Yahoo, Zend and Zimbra. They intend to
promote Ajax's promise of universal compatibility with any computer
device, application, desktop or operating system, and easy
incorporation into new and existing software programs.

Whenever an industry group gets together, it makes me nervous. As often as these bodies set standards, they also subdue competition and, consequently, innovation. Certainly standards for AJAX need to happen, but not too soon, before the technology has had an opportunity to ripen. We can't have 150 or 200 frameworks for the long term, but for the short term I think they are healthy. Seeing that this group seems dominated by the client-side component framework crowd (Laszlo, Google, etc.), I'm a little nervous that the server-side component guys like ZK and Echo2 will get short shrift.

It's too early to say which way this initiative will go, whether it will be just an empty marketing effort, a useful open standards effort, or an evil, anti-competitive mud wrestling spectacle. Do keep an eye out, though. In the words of Don Deutsch of Oracle, "The creation of software standards can seem academic. In reality, it’s big business."

• Digg
• Reddit
• del.icio.us

Comments (3)

Software Development