As one working exclusively on CSS-based layouts (that’s it, a little markup and a lot of CSS) day in and day out, I readily admit that it’s a tough thing to learn to do and it’s not an easy thing to master. Ben Henick’s 12 Lessons for Those Afraid of CSS and Standards serves both levels by presenting ideas that the novice needs to know and the intermediate needs to master. I recommend clicking that link and reading the article, no matter what you’re level. I’ll provide some of my thoughts on the article below (I’ll even try to make them match his order).

1. CSS is a very functional language. You really should think of it as an object-oriented language powered by inheritance and contextual properties. This is confusing at first (why does my headline render differently in one column than another?) but immensely powerful (I can make my headline render two different ways in two different contexts).
2. Rendering engines cause rendering bugs that make perfect presentation of a design very difficult. It’s not impossible, though. Using tools like position, you can really measure and execute designs to the pixel.
3. Most people don’t understand the skill and time involved in battling browsers, especially when your company or project is firsting starting out down the CSS road. It takes a while – especially for a new CSS programmer – to figure these things out and learn how long "simple" tasks will take.
4. I’ve fallen into the div-soup trap before. Real CSS mastery occurs when you realize that you don’t need divs anymore, that you can do the same thing using all those "basic" html tags that you’ve long forgotten.

5. In many cases, the person responsible for a site’s graphic design is not responsible for any other aspects of site implementation. When paired with a failure to create strict site- and section-wide wireframes, this lack of accountability results in unique comps for too many pages, and thus a lot more work for the stylist and producers.

   Please, designers, create consistent designs. There’s no reason why your columns should vary by a few pixels here and there. There’s no reason why a site should have more than a few base templates. Designers can either expidite the build process or bottleneck it with their creations. And, believe me, I’ve designed and built. When I design with building in mind, my design works better with fewer compromises.

6. Tracking down browser bugs takes time, and it’s most often that crunch time when a project is in its final phases. It’s a hectic thing.
7. The author left out one big benefit: really taking advantage of the cascade lets you do things, and change things, quickly. Want your left-hand links to be green? Tight CSS makes this a snap.
8. See #7. You don’t need all the markup that you think. This is a hard concept for novice programmers to grasp: their quickest action is to wrap everything in a div, style it, and walk away. I prefer to use divs as selectors, then use normal HTML markup as children of that selector. This makes stylesheets easy to read and easy to change. Plus, by using normal HTML markup, you can really improve that SEO, which everyone loves.
9. Without stylesheet hacks, your site won’t work. Plain and simple. Yes, /**/ is not valid CSS, but it works. Try to write code with standards and mind, but avoid blocking on standards. There are cases where you will need to eschew standards to get your work done. Don’t stay late looking for a "standards-compliant fix" when you won’t find one (believe me, I’ve looked), and the hack is the cleaner, easier way to go.
10. There’s nothing like writing a whole page, getting it into production, then seeing the "peak-a-boo" bug dropping off some text for no discernible reason. Or having blockquotes slowly shift your text off the screen. Or having…
11. position:relative is usually the first thing I try when trying to fix an IE bug. line-height sometimes works, too.
12. A background image on an <h1&gt makes a lovely, accessible, SEO-friendly headline. Standard design templates let you use and reuse backgrounds. Reusting common elements means less new browser bugs, and shorter development cycle, and much happier developers.

You can tell I’ve been doing this for a while, eh?

technorati tags:css, learning css, front end development, design, web standards, web development, front-end, user interface development

Blogged with Flock

How many programming languages have styleguides? Just about all of them. How about "web languages" like HTML, CSS, and JavaScript? On the development team level, there’s probably a lot. But there’s nothing close to the universal standard that Java enjoys. How do UI developers write code that other UI developers can understand? They use something like Dojo’s JavaScript styleguide.

Adopted from the Java Programming Conventions Guide, Dojo’s JavaScript styleguide is the common syntax that Dojo’s developers use. The Dojo Foundation is no slouch when it comes to programming, and they’ve created a styleguide that encapsulates many of the "standard quirks" of JavaScript development (like smooshing together if-else blocks and placing {s on the same line as your function header). In all, it’s an effective resource for getting everyone (especially Java guys who refuse to do anything in a non-Java syntax way) to write code in nearly the same language.

technorati tags:javascript, styleguide, development

Chartreuese gives us Why Paris Hilton Is Famous (Or Understanding Value In A Post-Madonna World). No, don’t laugh when they point out what Paris Hilton does well (no, really): she drops names. What does this accomplish? Everyone loves free publicity, and she gets free stuff in return.

So, how can this help you, the web developer? Use Paris’s mantra: if you give free attention (in our case links outward), you’ll get free attention back (in her case, $2000 sunglasses, in our case, links in). If you want to be noticed, give notice first to those you want to take notice of you. You’d be surprised how many people will follow a trackback, and how many visitors you’ll gain from something so simple. Instant SEO based on this almost-Golden Rule: do unto others so they will do back to you.

technorati tags:seo, marketing, trackbacks

Blogged with Flock

How much could you possibly want to know about CSS opacity? Mandarin Design covers just about all of it here, including a look at how to achieve "Photoshoppy" image and text effects using just CSS.

Here’s the biggest thing to remember when working with opacity? You’ll need to use a couple different flavors of opacity to maintain cross-browser compliance:

• Firefox lets you use the real deal, opacity and the proper range of 0.0 to 1.0.
• IE makes you use filter:alpha(opacity=x), where x is a number from 0 to 100 (see-through to fully opaque).
• Older Mozilla browsers require -moz-opacity, which ranges fom 0.0 to 1.0, like standard opacity

My personal opacity favorites: using opacity on an image to create a CSS-based drop shadow, and using opacity on a large background element to create a transparent overlay on a page. Both give that Photoshop-quality look with pure CSS.

Ever need a character code for that one goofy character you have to stick in your HTML? TnTLuoma.com has one of the most-comprehensive character code lists I’ve ever seen (and I’ve seen a lot of them). I keep this one bookmarked at all times.

While on this topic, here are a couple tips for when and how to use character codes:

• If you’re building an email, always use a character code and make sure to substitute character codes for non-standard characters when pasting from a Word Doc. Read that last part again. You cannot paste from a Word Doc into an HTML file and expect it to work. MS uses special, decorated qutoes and apostrophes that wind up (most often) as ? in your HTML code.
• Use the numerical code equivalent, because textual code equivalents are not always supported. While numerical codes are not guaranteed support, they are better-supported than their textual equivalents (and every textual code’s numerical equivalent is supported while the reverse is not true).
• Always preview your HTML when it contains character codes. It’s very easy to forget that last ;, the code istelf might not work, and these items look better and different font sizes (generally a larger size than your document’s base font). Preview, preview, preview!

technorati tags:html character codes, ascii, ascii codes, html, web development

Here’s a kind of annoying one. If you’re doing development on forms, odds are at some point in time you’re going to want to pre-select a radio button. Doing that is simple:
<input type=”radio” name=”myButton” value=”myValue” selected=”selected”>

So, you add that to a form element, and, like any good developer, you’re using FireFox to test as it’s more accurate rendering engine means you can develop compliant pages. Of course, your radio button remains unchecked. You can refresh as much as you want while tinkering with your code, but it probably won’t ever change. Why? FireFox caches radio button selections basically forever. The only way to get a true look at radio button values is to perform a hard refresh (CTRL+SHIFT+F5 on the PC). Now your box is selected, as it should be.

That’s the Golden Rule for FireFox Form Development: always make sure your cache is clear with CTRL+SHIFT+Refresh.

Blogged with Flock

Sorry it took so long to get all the recaps done, but I wrote notes until my hand locked up, so there was a lot of material to cover. Here are my thoughts and observations on the conference:

• Web 2.0 is not just a marketing buzzword. In fact, Web 2.0 is the next step in the de-emphasis of marketing, and the emergence of user experience is a driver of business. Pretty much every service is covered on the web. We all know that, after commoditization of a product or service, comes competition based on differentiation bred by customization, positioning, and, ultimately, quality of service. In the web’s case, quality of service is primarily influenced by customer experience: provide a rich experience, and you’ll gain - and retain - customers. Successful sites have great experiences; great experiences build great communities; great communities will pay just because they like the service. Notice how there’s no marketing involved here: there’s not million dollar media buys, email spam, and text links wherever you can get them. Word-of-mouth is king.

  Take Google. I love their services; they provide me with a great customer experience. I would gladly pay $5-10 a month just to keep using things like their search and Gmail. Did I decide to do it because I saw their ad during Lost? Nope: They don’t advertise at all. There’s no need to market a great product or a great service that is built into a great experience. (Or, perhaps, this anti-marketing is the next step in the evolution of marketing?)

• Good design is not often innovative design and a good design for one site may fail miserably on another. There’s no formula for a good design (no, "clean" is not always best; look at Netflix which is very usable but kind of cluttered). In fact, good design is a design that enables the user: it exposes and emphasizes the features and paths that the user needs, provides easy methods to interact with the site and data, and provides visible and immediate feedback on user actions. A good design for a site may not be beautiful, but it succeeds because it is functional. Great designs wrap beautiful presentation around beautiful channels for interaction, around easy-to-use features, and easy-to-find paths. A great design builds that great user experience, which in turn builds a popular site.
• Usability is now totally different. We’re mixing the context of applications with the context of web browsing. How do users see complex web applications? Should they react more like desktop application - with full undo, state saving, etc. - or should they work more like traditional web pages, only with a few souped-up features? It’s too early to give a sound recommendation, because users haven’t formed any distinct mental models around what Web 2.0 apps are supposed to do. After more exposure to advanced web apps, users will slowly begin to decide that "this is what a web app is supposed to do."
• Web 2.0 is about the creating the "duh" service. A site that lets people collaborate on projects? Duh. A site that lets you keep track of people in your network? Duh. A site that lets you meet friends with similar interests? Duh. That’s what Web 2.0 is. Web 1.0 (maybe Web beta?) was about seeing what could be done and living off the "wow, this is cool!" factor that arose because we’d never seen this stuff before. Now, it’s very much "been there, done that" when it comes to the sheer technological wow factor. Now, we actually want to use things that serve some sort of purpose: the "only cool" products burst with the rest of the bubble. Web 2.0 is about finally putting products that serve a need, no matter how small, on the web; it’s mass production to serve mass needs. The "duh" services are driving the new boom: think of Flickr (let’s make photosharing easy, duh!), Basecamp (people need to collaborate on projects, duh! let’s do that), and YouTube (there’s a lot of great videos out there, what if we could collect them all so, duh!, they’re easy to find and search). These are the services that are now spiraling to huge popularity and massive VC funding.

The new generation of web applications are about giving users access to the things they need and the ability to do what they want with their data. More and more, companies are starting to realize that success comes to companies that give users what they want, not to those that try to market things down users’ throats. By creating user-focused web applications with enabling designs, companies can create engrossing experiences, the type of experience that brings users to a site and develops strong communities around those sites. By focusing on engrossing, positive user experiences, Web 2.0 means success for both companies and, ultimately, users.

Next Generation of Web Applications - Panel (Jeff Veen, Google; Mike Migurski, Stamen; Steve Mulder, Molecular; Rashmi Sinha, Uzanto; Jared Spool, User Interface Engineering.

[This was pretty rapid fire, so there may be more ideas than salient sentences. The panel members had a lot of fun goofing around and interacting with each other while producing some great ideas on the next generation - or some might say now-current generation - of web apps. Jeff Veen led the panel; all questions, unless indicated otherwise, came from Jeff.]

Uzanto produced The MindCanvas for rapid customer research.

Stamen - Mappr and Digg Labs. Stamen focuses on loose client relationships, on goals versus a set project. 3-4-5 month engatgements where you think about what to do. "We put out the kind of work we want to do."

MindCanvas - [in a demo of the MindCanvas card sort app, Veen drags Yahoo! and Microsoft into a group which he names "Stuff I don't use."]

Marketing MindCanvas? Just word of mouth: "No-effort marketing."

Why Flash? Flash provides an immersive experience (sound, etc.). When building applications like these "use what makes sense." Don’t be locked into Flash or AJAX for rich apps: use the platform that best enables your idea.

Stamen - Visualization technologies: AJAX limits you to "right angles."

Development process? Three people working together. Sometimes the amount of people is dispersed. Too many projects is a problem.

How do you collaborate? Definitely [can't read my writing sorry]. They use Optiwrite to turn a wall in their office into a collaboration space.

How do you convert or build ideas to Flash? Go down to the deep back-end level early. Flash is a "last step" after data.

JV: How about with Mind Canvas We’re a remote team. How to work together is a huge learning. It’s either email or Basecamp. Each morning we have a "scrum" meeting to see what’s going on. [I've seen that a lot with small companies or small project teams: with a very small, close-knit group it's very easy to have a quick sit-down meeting each morning to figure out the plan for the day, discuss what everyone's working on, set priorities, and talk about anything that just popped up. -A] At most there’s five people on a project. Their work process:

1. Prototyping
2. Paper
3. Draw together (using Yahoo! Doodle over YIM
4. PowerPoint

[Steve]: PowerPoint can be used as a design tool for animated wireframes. [shows a quick demo of a pretty interactive PPT mockup]. "It’s got the YFT [yellow fade technique], right in the wireframe! Come on!"

In many cases, designers need an anti-prototype tool to avoid customers saying "let’s ship it now!" You have to make it intentionally unshippable.

[JV] What about the usability challenges? How does the fundamental way people think of web apps change? I slide a slider: what does the back button do? We can teach them.

Some thoughts on that? [Jared] It’s all about context. It looks like there’s nothing happening. Make sure where they’re trying to go is clearly delineated. The browser wasn’t intended to be dynamic. [The back button] is almost vestigial.

[JV to RS] I notice you turn off all the chrome [in the browser].
It’s about grabbing all the attention. To date, nobody has ever said they have a problem.

[JV] It may be heuristics or context sensitive.

[Audience] Trying to communicate which context you’re in (application vs. browser) is the most difficult.

[Aud.] How do you involve users in building apps?
[JV] I’m working on a project where we did a lot of up-front research. It’s more about how are people successful and how do they show their success within the organization. [After that research we] moved immediately into prototyping.

[JV to Steve] Do you use prototyping in PPT to users (or show PPT prototypes to users for testing, interaction, etc.)? It’s limited because there’s only one path [in a canned prototype]. We’ll do a quick HTML prototype that’s just rich enough to be testable.

[JV] My team is comforatble with throwing away their work. 90% is thrown away.

[MM] We try to start building from the start.

[RS] We did user testing throughout and iterated off that. We weren’t testing for usability only: we were testing for [whether or not the user was having] fun.

[JV] With current web apps, is there any difference in usability testing techniques?

[JS] Whenever you put a design in front of people, you’re trying to see it through their eyes. Anything that gets them to share what’s in their head is good. Paper prototypes. Clickable PDFs [are the same as paper], that’s just work that isn’t returning any value. Just draw things out on paper. Paper prototyping is worth investigation. You just need to sit next to soeone and watch them use it.

[One of the presenters mentioned Paper Prototyping by Carolyn Snyder].

[Aud.] My company is just starting on a global project. How (do we do it, get started, etc.)?

[SM] Go to the customers. A lot of what doesn’t change is know your audience, know what they need. Getting out there and talking with real people is always first.

[Aud.] How do we [I believe they meant designers] drive technology so that Web 3.0 is what we need? How do we harness the development energy?

[JV] Projects come up through &quot20% time." By the time it’s on the radar, it’s already developed. This generates a lot of technical innovation, but then we get things like Google Base, which makes people scratch their heads.

[MM] It distributes the idea process. Not every release has to be successful. If you’re thinking about usability, you should find context in the past.

[RS] Everyone at my company cares about design. I have a great deal of respect for the engineers. We as a design crowd need to think like that. Just thinking about usability can hold you back. Marry technology with what people want.

[Merholz from audience] PPT wireframes show tension between page design and space design. How do you design these spaces people will be using?

[MM] We built a prototype. It crashed under unexpected weight. It’s definitely a crapshoot.

[RS] The key element is what people are focusing on, what they’re watching. [Letting them know] this is available.

[SM] Optimize for common usage, then make it scalable. Build hooks and flexibility around it.

[Audience guy] Here’s how to standardize the back button: if a user can’t undo the last change they made, they’ll go for the back button, and that’s what it should do (act as undo).

[I'm all in favor of a back button API that would let us hook undo functions into back, but just image the implications of a programmer taking over a user's back button and overwriting a browing session's history, essentially hijacking a session. Perhaps, there should be a hook for CTRL + Z or Edit -> Undo that would let programmers provide code for backing out changes? That would be GREAT! -A]

Mobile Experience Design - Anita Wilhelm

"The future is mobile"

What do you think of when you think mobile design? [audience] screen space, no keyboard, no standards

Mobile design must take into account that we’re now interacting with devices that weren’t meant to do what we’re trying to do with them. We’re left with using the phone as a joystick due to differing hardware, and poor APIs.

mFoundry, a mobile UI company, has built an interface that makes it easy to input data, but, still, how do you submit a form?

The common metaphors we see in the web space are changing in the mobile space: hardware buttons must take the place of software buttons. Mobile design is not just about a smaller screen, it’s about cramming the web experience into a phone, which is ultimately design first for calling.

Furthermore, when we’re designing for phones, we are designing as we’re moving through users’ lives: users are always connected to their phones, they always have them.

4info has adapted search to the mobile market. In part, they are successful because they don’t overburden the user with information. They’re also monetizing their offering.

Caterpillar, Anita’s company, learned in user research that advertising in SMS that it doesn’t matter how many ads the user gets as long as the ads are always relative to the txt message or further helpful: if a company pushes an ad for Fandango to a user txting searches on movie times, then the user will accept those ads and act on them.

A new question that pops up in the mobile space is what happens when all a user’s personal info is stored in a mobile device? We’re then forced to move into the realm of "private" design: finding ways to hide users’ personal information while not being too intrusive.

[audience] What is the disconnect between the US market and high-tech Japanese phones? [AW] The US is 2-3 years behind. It’s not a cultural difference but is more due to [carrier] business decisions.

[audience] Is the mobile market piling on too many features? [AW] When you start coupling all these things together, you’re taking away from the best design possible. The phone soon will become almost like a backup to other devices: the computer will have the rich interface; the phone will have a scaled down interface as it’s a secondary device.

[audience] What about voice-driven apps? [AW] They should be the key, but voice recognition software is not very good. It’s difficult for the end-user to set up (and a difficult set up means little to no adoption - A). Voice recognition is not a very near effective solution for interfacing.

[audience] With hardware manufacturers cramming more features in, what about older users? (A - he seemed to be saying that, as users get older, they’ll have an increasingly harder time to actually see and type into whatever interface we put in our mobile device). [AW] As interfaces get better, it will be easier to read these things. Bigger phones have more weight making them easier to hold and use.

[aud.] Location-based services: can technology development outside the mobile industry functionally go around the carriers? [AW] The only thing that would be possible [to let developers do an end-around the carriers] would be something using Bluetooth because US carriers own all the highways.

[aud.] What’s a good move in the short-term to boost e-commerce on mobile devices? [AW] In South Africa, it’s cheaper to install mobile infrastructures. There, you can buy goods in the market with your phone, helping farmers to keep track of their inventory. E-commerce is driven by need; cheap mobile satisfies that need.

[aud.] How far ahead are other countries? [AW] In Europe, you can buy train tickets with your phone. In Germany, you can rent bikes with SMS.

[aud.] How do you advertise mobile software? [AW] 1.) Many game publishers have the option of going straight to a carrier. However, there’s a big push to go around carriers. These publishers believe that "if we own the users, we don’t need the carriers." 2.) Use non-traditional media and direct marketing.

[aud.] What is the dispartiy between doing client-side apps and SMS on a mobile phone? [AW] The pure benefit is presentation. It keeps the user locked into one experience. Once a user has opened an application - which is the hardest thing - you can load more information with HTTP GPRS than with SMS.

[aud.] Is there an organization helping to organize a standard devlopment platform for mobile devices (there’s BREW, J2ME …)? [AW] I don’t think it will be as standard as the web. There are too many manufacturers, and all think the phone has different functions. In the future, there will be more compliant APIs that will allow developers interact with new parts of the phone, like cameras and keyboards.

[slide notes]
(3) There are three times more phones than laptops. In most of the world, the first Internet experience someone will have will be on a phone.
(9) The phone is an intimate device: you always have it with you.

[AJM] This is where it’s going. The real challenge for designers is working with a lot less real estate at a lot lower resolution: there’s not much room to play with, so choosing which features to present and which features to make prominent can make or break an interface. For anyone doing anything in the mobile market, the challenge is figuring out whether to work with or work around mobile carriers: they have the market locked up, but, if you build a product that people love, they’ll use that product whether or not it has their carrier’s stamp of approval. I believe that the carrier is secondary: users see - and want - the products first. If you make it great, they’ll buy it.

The CSS background-color property makes things look nice and pretty. But, they don’t play well with margin in a block-based layout where the body tag’s background-color is different from your content’s background-color, especially when you’re using a liquid height layout.

Let’s say you’re stacking three divs on top of each other for a nice stack. That middle div has a background-color. Now, adding a block-level element with built-in margin (like a p or h1) to that middle div will cause a big huge band of color where the element’s enforced margin pushes down the block beneath it. (Is it a bug? Nope. Just doing what it’s supposed to.)

How in the heck to you get rid of that band of color? Simple: add something below that block-level or margin-enforcing element, or add padding to the block-level element’s container. The margin is enforced on the item below, which gets pushed down, but also stretches the container’s height, keeping the color in tact. Ditto with the padding: the padding forces a height on the container, keeping the background in tact and delightful.

Feel like playing with margins? Give a margin-bottom of 0 to that problem element. Or, give a margin-top of a negative value to the block that’s being pushed down (it’s roughly the line-height or specified font-size that’s in effect on the container).

There’s four simple, friendly ways to make margins play nice. The third is probably the cleaneast; the fourth the dirtiest (especially if another developer doesn’t see that negative margin, and wonders why blocks are overlapping after he’s made a change to the code). But, all do the job.

technorati tags:css, background-color, margin, html, liquid layouts