Just a quick post, as I noticed the header of the RSS aggregator here at Adobe just changed it’s graphical header from the old-familiar ‘Macromedia XML News Aggregator’ to ‘Adobe XML News Aggregator’. Not sure of any larger context/changes behind the graphic switch (although had suspected it was coming for some time), but must admit finding myself a bit nostalgic at the moment… :)
Archive for September, 2006
The next question from Dallas’ design panel is one from Neill Harmer:
“I keep hearing ‘we can fix that with CSS’. Do you ever see CSS getting to a point like HTML – where we are asking it to do too much? Meaning – what is CSS’ ceiling?”
Good question, and one I’ll probably have a slightly different view on 6 months from now, and again in a year, and so on… ;-)
Answer: In some ways we’re already hitting various ceilings within the current CSS specs, but it centers more to browser differences/limitations being the ‘ceiling’ (at least for me), and of course having the current working proposals in progress at the W3C nailed down so they CAN be implemented.
There are a lot of CSS3 features that I’m really interested in being able to use myself, specifically multicolumn layout and paged media (so you could even look at these being ‘ceilings’ for the time being), but it really depends on when these specs are finalized… and then implemented in the browser. That’s usually the gating factor in my opinion, cross-browser compatibility. If you follow the forward-looking draft specs at the W3C there’s plenty of cool features on the horizon we can’t get to, which is more a case of wanting shiny new toys instead of being happy with where we’re at right now. I guess you could call that a self-imposed ceiling of sorts?
There’s a pretty good list of CSS limitations on wikipedia I like to refer to as well, which sums up some of the current thinking on this subject much better than I’d be able to in a single blog post:
Honestly, this is a pretty open (and subjective) question that would have really benefitted from a panel discussion – so feel free to pop in your own opinions/thoughts in comments as well. I’d be really interested in seeing the limitations of CSS from others’ eyes myself.
I normally don’t take bait like this, but after JD forwarded me this article on Acrobat Connect (nee Breeze Live) by WhatPC’s Guy Kewney titled “Will Acrobat Connect be a Conversation Stopper“, I have to respond to the article’s assumptions, starting with:
“(Connect) is one of many trying to recreate the old chatroom mentality.”
Now I can respect an alternate opinion, but Connect is anything BUT a regression to the old chatroom mentality (although it does support text chat as one of many communication mediums, sure – and I’d likely buy ‘an evolution of the old chatroom mentality’ as a more germane statement). VoIP (as well as direct phone bridging for those without headsets and broadband connections) is supported for real-time voice communication, falling back to chat pods for text-based discussion. But when’s the last time you were able to access a live screencast of a remote computer inside a text-based chat? I’d wager the answer is ‘never’.
“But the trouble with online conferencing is that you can’t see or hear the response to your comment for a day or more. They call these systems “interactive” but they aren’t. You see a message, and you respond – in full – instantly – but you don’t get a response until you have finished, posted, and your correspondent has replied.”
A day or more? Seriously? In this age of pervasive IM, text messaging and email? Even my 9-year old nephew can grok context from an IM window, and has a startling vocabulary of emoticons to qualify his more abrasive (or convoluted) statements.
But aside from rapidly changing social norms, I and many other regular Connect users also regularly use a USB or FireWire webcam to participate in online sessions (yes, video conferencing is also supported within the application) to provide the extra context, nuances and small facial tics that do indeed enhance the social context of live conversation. Particularly for more animated speakers like myself, who don’t always have time to bang out an emoticon to follow every phrase, and use a lot of body language to enhance my spoken words.
Now sure, I’ll buy that online discussion and collaboration can be a different – and sometimes disassociated – experience than real-world meatspace interaction, and requires a shifting of communication style and delivery to best leverage the medium, but Connect is far more than text chat with no social or reactive context. Screen and slide-sharing allow visual support and context to visual, audio and textual ‘chat’ within a Connect meeting, more than one layer of social context that the ASCII chat experience the article seems hell-bent on associating Connect to. Connect is a far different beast- we’ve come a long way from ‘Prodigy, BIX and CIX’.
After using Breeze (and now Connect) for years, my takeaway from the experience is that it’s dramatically improved my ability to connect with others – something many user groups around the world who have hosted me as a guest speaker via Breeze/webcam/VoIP can likely attest. I can reach a user group in Tokyo from my San Francisco home office visually, interactively – and yes, even textually – in ways I could never dream of with a simple IRC channel or even enhanced IM/chatrooms. Remote audiences can see my face via video (and I theirs), while hearing my voice via VoIP, and seeing what’s happening on my screen via screensharing- all from one interface that’s accessible by any Flash-enabled web browser. Chat room mentality? Not even close. Not by a long shot.
“What you need, of course, is an AI avatar which responds with a hurt, or apologetic, or amused face, based on the likely response of your correspondent. It’s all very well putting your own “smiley” into online conversation; but what “interactive” means, is that the other person’s smile is seen in response. Without that, you could start a fight.
It’s all Adobe’s fault. Why can’t they understand a simple point like this? They must be really, really stupid…”
Now without providing even a non-AI emoticon or avatar to qualify the tone of that last sentence, isn’t Mr. Kewney breaking his own standards in regards to online communication here? Ironic, inflammatory, and more than a bit contradictory at best… ;-)
But to be fair, I’m also not including a visual transcript of my facial expresions while typing this post, nor do I have any interest in starting an arbitrary squabble over what seems to me to be an obvious disconnect with facts. I find the article a rather ill-informed piece, in my opinion- but Mr. Kewney’s certainly welcome to his own opinions, regardless of how much I disagree with them… ;-)
(Disclaimer: I should note that I’m not a member of the Connect team, but a regular internal user of Connect – in many respects, no different from any other end-user. But as I do work for Adobe, this post could be construed as a commercially-biased opinion- which it is not. I’ll leave such judgements of my character to you, the reader.)
Question 3 from last weekend’s unanswered list is from Mike Lyman:
“What is the best software to use to A/B test a site w/changes to get better conversion?”
Great question. My answer’s probably going to be a strange one- the best software is eyes, brains and fingers. To clarify that (which would seem necessary, eh?), I prefer to do direct usability tests of the site at different phases of the project – pre-testing before determining new designs, post-testing of new designs/layouts, and then very careful click/path analysis after launch to see if the ‘real world’ reaction follows suit. (I’m hoping you got a chance to see Jared Spool’s session at the Jam Session- which probably answered this question far better than I could).
There are, of course, eyetracking software packages that can literally tell you where user attention goes in relation to a page design with stunning degrees of accuracy (Morae being my favorite – which may answer your question, but keep reading, please!), but I usually fall back to a warm body in a chair- specifically, the users of your site. Recruit a few site visitors (perhaps people who have responded through online contact forms, or expressed issues with the site already?), and then determine the real user paths you want to support with the design/layout/navigation, and create specific, goal-oriented test cases – then record the results. You might even want to consider the same tests with people who aren’t familiar with your products and services and site, to really see what a fresh set of eyes and opinions can bring to your current design.
For example, if one goal of your redesign is to improve the conversion of inbound clicks to sales, a use case could be simply ‘from the home page, find a product that lets you do (X), and then purchase it’. The paths and flows a real-world user will take may astound you, but are priceless in determining how link structure, site navigation and general design may be hindering the simplest of tasks.
This ‘first round’ of testing usually drives the requirements for the redesign. For example, if no one clicked on the ‘store’ link while performing the task example above, but instead shopped the products section of the site and added items to a cart from their catalog pages, you may want to examine the position and relevance of the store link entirely – or perhaps make the catalog itself more front-and-center in the design/navigation so less clicks are required to find and select a product for purchase.
A second round of testing with the new design/layout/site usually helps validate your design decisions. Did the user task behavior change appropriately to better support your goals? Or did it introduce new problems? This way you can start drawing direct correlations between cause and effect- how your design affects user interaction.
I realize this may be a bit of a dodge of your question- which software best supports this process – but honestly I have a minor lack of faith in heuristic software to find these navigational and design shortcomings, as they just don’t mirror real humans clicking on real links, buttons and items on your site. Plus, the manual approach is far more fun. ;-)
Jakob Nielsen has some good (and recent) thoughts on user testing here, and of course I’ve adopted many of my own opinions and thoughts on UE testing from Jared Spool and the UIE team (attended my first seminar with Jared about 10 years ago, and the advice I got there has stuck with me to this day).
Hope this helps answer your question (specifically as this is not my forte, but something I’ve done a lot and really enjoy), if anyone has additional thoughts/critiques, please bang out a comment below.
If you’ve been stumped by the Flash 8 Video Encoder’s settings, or wondered why your FLV videos stutter, jump or otherwise choke on a broadband connection, you’ll want to read this article I recently co-wrote with Community MX’s Tom Green – “FLV Data Rate and Bandwidth… Demystified” – which is now up on both the Adobe Design Center, and Community MX.
Both Tom and I have been speaking on Flash, After Effects and FLV fairly regularly this year, and when comparing notes at TODCon ’06 in Orlando earlier this year, were astounded at some of the wild-and-crazy settings people were using to encode their FLVs, and the varying misconceptions as to what the settings actually encompassed. But more concerning was the amount of people who just got frustrated with basic Flash Video because it ‘didn’t just work’ the way they’d expected it to. Well then- this article should answer most of the questions we’ve heard in our respective travels so far, and we both sincerely hope it helps clear things up and get you posting more video on a regular basis.
And of course, if you happen to catch either Tom or I at conferences/speaking gigs and have more questions, don’t be shy- come on up and say hi!
The second question this week is from Guy Huntley:
“Comparing CSS to classic Tables/Frames – how much less time does CSS take to create a page? How much less time to modify a page? How much more efficient is CSS vs. classic techniques, and can it be quantified?”
Hm. Now keep in mind that it’s very difficult to estimate exactly how much time it would take to create a page in CSS vs. older methods without seeing the design you have in mind, and it’s specific issues and requirements.
Generally speaking, it doesn’t take me much more time to flesh out a page in CSS than it would in traditional table layouts. If you’re new to CSS, then sure- it could be a bit hair-raising your first project or two, but any new technique does take a bit of breaking-in to get used to, IMHO. CSS is no different.
Now that’s my take on CSS for creating new designs- but when it comes to updating them? CSS is LIGHT YEARS more efficient, no question whatsoever. If your design markup is scattered throughout your content in each individual HTML file, you’re going to have to touch every file that uses the design to update it. Sure, templating systems and cunning use of #include files can reduce this nightmare, but what’s not to love about the CSS update process- tweak a stylesheet or two (there’s usually not more than 3 or 4 stylesheets in my projects), watch the entire site suck up the changes in seconds. Simple. I would estimate that even if I didn’t save ANY time (or even lost time) creating a new page in CSS as opposed to table layouts, all the iterative updates to ‘child’ pages is so much easier in CSS that at the end of the day I’ve spent less time working with the CSS version.
(And surprise- you can also play those old-school-but-quite-valid #include and template server-side trickery with CSS layouts as well, further reducing your time required to touch all the assets on your site. It’s really a win-win.)
My recommendation, spend the time to tackle the CSS learning curve, and move forward instead of backwards. You’ll start to see the benefits of CSS almost immediately- and whether or not they’re quantifiable to your clients and projects is really up to you. I’ll never go back to purely table-based designs, personally- and suspect after the initial pain of learning a new skillset is past you, that you’ll agree.
Well, that’s my opinion, at least. Feel free to rip on it in comments if you disagree, and I’ll see you tomorrow for question #3. ;-)
There were a lot of questions submitted to last weekend’s panel Q&A in Dallas that I didn’t have time to answer, so will answer one each day this week. First up, Bill Miller asked:
“Should we aspire to ditch all table/cell markup in pages and use CSS? Are tables still a good thing for pages?”
A: In order- no, and yes. Let me qualify those answers. Tables were originally designed to hold tabular data- any data that is best displayed in rows and columns. In the early years of HTML markup, they also became a defacto way of creating ‘grid-based’ layouts, before CSS was defined and implemented in browsers to help replace tables as a design tool, and provide a better (and more precise) way of laying out pages. But no, I don’t think you should ditch all table/cell markup in pages just for sake of using CSS – but instead use each where their strengths lie. It’s really more a ‘use the best tool for the job’ decision, in my opinion (and trust me, there are some widely-varying and heated opinions on this topic).
In a perfect world (at least mine), your data/text/content would live in the (x)HTML page, and your presentation/design would live in a CSS stylesheet. Clean separation of design and content is the goal. If you’re finding yourself using lots of nested tables and spacer images to achieve a design, you probably should step back and ask yourself how that design could be achieved in a more standards-compliant way using CSS. There’s usually a way to do it that’s more forward-looking than the crusty old table methods of achieving ‘grid layout’ designs, spacer GIFs to force widths/heights, et al. Sure, it can present a learning curve, but the reward is well worth the effort- CSS really is amazingly powerful for achieving just about any visual layout you have in mind, and if you don’t believe me, just go spend a few minutes at Dave Shea’s CSS Zen Garden website. (Dave’s got some interesting points to share in a podcast interview I had with him last March on this subject, too.)
However, if some of the content in your page needs to be displayed in a tabular format, there’s no reason to not consider using a table to contain it. That’s what they were originally designed for, and an absolutely valid reason to use tables in a CSS world. Don’t run screaming from the <table> tags arbitrarily- there’s still plenty of room for tables in a standards-compliant CSS world. But it’s usually more for formatting content, in my opinion, as opposed to realizing your global page designs. That’s where my line is drawn, and I’ve found it a pretty good rule of thumb which has made design updates (especially on large sites) a snap by just updating a few CSS sheets, and kept my XHTML pages clean and uncluttered so they’re less confusing for the less technical folks who may need to update the content within them from time to time. Without access to the CSS, I don’t always have to worry about those less technical clients/editors/etc. blowing out a table cell during a simple content update and destroying my entire page layout! I think you’ll agree, that’s a pretty nice byproduct of moving more towards CSS.
But if you’re new to CSS entirely, it can be a deep learning curve. Start small, perhaps move more of your formatting and styles to a CSS stylesheet first, and then slowly start working at removing those outer nested tables and replacing them with DIVs that you can position via CSS. It’s always best to walk before you run, of course- but once you’re up to full speed with CSS you’ll probably be very glad you made the effort.
And that’s my take on that debate… ;-)
Coffee Cup’s J Cornelius just posted his photostream from last weekend’s event in Dallas (joining Giovanni Gallucci’s photostream of the event here), and you can check it out here. You can also see ALL the photos tagged for the event here. And if all this Jam Session activity piques your interest (which it really should), visit the Webmaster Jam Session site and sign up to get pinged when the 2007 event(s) are announced, I guarantee this is one event you’ll want to catch next time around.
Very tired. Must fly home now. Quite content-sated, and smiling wide. Today kicked off with a web design panel fielding questions – hosted by Coffee Cup Software’s CEO Nick Longo, and featuring (l to r) UE expert and Digital Web Magazine founder Nick Finck, myself, Nick Longo, design superhero Andy Budd (who can rock the mike with the best of ‘em!), CSS rockstar Eric Meyer, Microsoft’s Chris Wilson, accessibility guru Derek Featherstone and Bryan Veloso, master of all things Photoshop. TheAgencyBlog.com’s Giovanni Gallucci gets the nod for this shot, and you can check out his entire event photostream here, too.
My session was from 2-3 pm, somewhat broadly titled ‘Adobe Product Showcase’, in which I demoed the Spry framework, and a little bit of Flex/Apollo/FAB goodness (note for the curious- if you caught the keynote or Danny/Christian’s Apollo sessions at Flashforward Austin last week, you got a much deeper dive! I just covered the highlights here). Thanks to everyone who attended, and all the great questions during Q&A (as always, I ran about 10 minutes long). I really love speaking at these events, as I always feel like I learn more from the audience than any book, weblog or news source.
Keep an eye out for upcoming Jam Sessions- well worth attending. The sessions were great, the speakers were STELLAR (well, with the possible exception of myself), and the CoffeeCup Software folks did an amazing job of pulling it all together so brilliantly for a v1.0 event. ;-)
One word- sweet. The Dallas Webmaster Jam Session has been an awesome conference so far, I’m glad to hear this is the first of many more Jam Sessions to come. Eric Meyer’s keynote kicked off the day with a great history (from a well-travelled point of view, I might add) of the long crawl CSS has taken from a well-intentioned spec, to a wide morass of varying browser support around the turn of the century, to the current state of cross-browser CSS with IE7 close on the horizon.
Derek Featherstone and Ethan Marcotte’s session followed (unfortunately at the same time as Chris Wilson’s IE 7 preso, which I’ll have to gem up on afterwards), a great deep-dive on why standards are important, particularly from an accessibility perspective. Great slides, too (apparently Ethan was dressing ‘em up just before the session, something I’ve been doing to my slides for tomorrow all day today!).
Ethan, Derek and I grabbed lunch after their session- and we caught up on all sorts of stuff- accessibility and Spry, why we’re all so busy lately, Derek’s Ironman training regimen (nice!). Nice to get a quiet conversation outside the big sessions, most definitely.
I’m currently in Bryan Veloso’s session, which is a great grab bag of tips, tricks, suggestions, and techniques on the venerable-yet-still-superhuman Photoshop. This man knows his stuff cold. I’ll be grabbing a quick coffee break before Jared Spool’s session on usability – ‘Good Content Must Suck’ – which should be a mandatory session, IMHO. Craig Clevenger (formerly the editorial counterpart to my webmaster role at now-defunct Santa Barbara software company MetaCreations, before he became a rock-star author) and I attended one of Jared’s workshops for UIE on web usability about 8 years ago to prep up for a major site redesign, and Mr. Spool doled out so much insight on the dirty truth of usability my head spun continuously for the next few years.
If today is any indication, you simply can’t miss the next Webmaster Jam Session, wherever it’s held. Fantastic speakers, great tracks and management, it’s definitely going to be one of my favorite cons this year (and after attending 2 Flashforwards and SXSW, that’s saying quite a lot). Kudos to all the guys at CoffeeCup Software (in particular, the organizational wizardry of J Cornelius) for such a kick-butt event so far!