paper & pencil

CSS - File Organization + More...

Two great CSS articles in the recent issue of Digital Web Magazine:

• Architecting CSS
  Garrett Dimon looks at the options available for organizing your styles.
• Strategies for CSS Switching
  Excerpted from Professional CSS, the authors discuss different techniques for style sheet switching.

Links within the first article led me to two more great articles:

• CSS Organization Tip 1: Flags
  Douglas Bowman of Stopdesign shares his method for labelling sections in his stylesheets.
• Image (Replacement) Maps
  Paul of Your Total Site shows how to use image replacement techniques for creating image maps.

AJAX & Interface Design

Luke Wroblewski's article, AJAX & Interface Design, examines some of the design implications of "quick, incremental updates" that AJAX enables.

AJAX allows every element within a Web interface to be individually and quickly updated without affecting the rest of the interface. This, of course, is not what most Web users are accustomed to. Initiating an action within most Web sites triggers the inevitable blank screen and page loading process. Though not very responsive, the full-page update makes it very clear to users that their action has resulted in a reaction and that a response will be available as soon as the page is refreshed. Because AJAX-based updates are very fast and incremental (often affecting only a small portion of the UI), users may not notice them -especially when they are used to seeing full-page rewrites.

web 2.0

Richard MacManus & Joshua Porter describe the six trends that characterize "Web 2.0" in their recent Digital Web article.

Enter Web 2.0, a vision of the Web in which information is broken up into “microcontent” units that can be distributed over dozens of domains. The Web of documents has morphed into a Web of data. We are no longer just looking to the same old sources for information. Now we’re looking to a new set of tools to aggregate and remix microcontent in new and useful ways. The Web of documents has morphed into a Web of data. We are no longer just looking to the same old sources for information. Now we’re looking to a new set of tools to aggregate and remix microcontent in new and useful ways.

These tools, the interfaces of Web 2.0, will become the frontier of design innovation.

To summarize, these are what we see as the six main themes covering design in the Web 2.0 world:

1. Writing semantic markup (transition to everything XML)
2. Providing Web services (moving away from place)
3. Remixing content (about when and what, not who or why)
4. Emergent navigation and relevance (users are in control)
5. Adding metadata over time (communities building social information)
6. Shift to programming (separation of structure and style)

Guide to Web App Technologies

Luke Wroblewski and Frank Ramirez published a guide on the various front-end technologies available — Web Application Solutions: A Designer's Guide.

Overview: Web Application Solutions is a guide that helps designers, product managers, and business owners evaluate some of the most popular Web application presentation layer solutions available today. We compare each solution through consistent criteria (deployment & reach, user interactions, processing, interface components & customization, back-end integration, future proofing, staffing & cost, unique features) and provide an overview, set of examples, and references for each.

sIFR

need to check this out further — Introducing sIFR: The Healthy Alternative to Browser Text

The following explains the sIFR process:

1. A page is requested and loaded.
2. Javascript detects if Flash 6 or greater is installed.
3. If no Flash is detected, the page is drawn as normal.
4. If Flash is detected, the HTML element of the page is immediately given the class “hasFlash”. This effectively hides all text areas to be replaced but keeps their bounds intact. The text is hidden because of a style in the stylesheet which only applies to elements that are children of the html.hasFlash element.
5. The javascript traverses through the DOM and finds all elements to be replaced. Once found, the script measures the offsetWidth and offsetHeight of the element and replaces it with a Flash movie of the same dimensions.
6. The Flash movie, knowing its textual content, creates a dynamic text field and renders the text at a very large size (96pt).
7. The Flash movie reduces the point size of the text until it all fits within the overall size of the movie.

accessibility primer

good article by Matt May in Digital Web Magazine — Accessibility From The Ground Up: A Primer for the Web designer

good point:

The hardest part of Web accessibility, in my opinion, is the stuff outside the angle brackets.

some good reminders such as using the summary attribute to explain the purpose of tabular data in tables and the use of abbr and acronym.

on accessibility testing tools:

If you or your team is going about designing a site blithely unaware that accessibility problems are being created, automated tools are not going to save you in the end. They’ll just confirm what you probably already know—stuff is broken.

Designers need to study the needs of accessibility and design it into their processes from the beginning. It is sufficient for most purposes to read a book or two on Web accessibility to understand the audience you’re building for, what its needs are, and how to satisfy those needs.

Nearly all of the automated tools in the market also return “manual checks.” My experience, and that of the developers of these tools, is that authors often gloss over these checks, or don’t understand what is really required. A basic grounding in the meaning and intent of these manual checks will help you to build more accessible pages—and save a lot of time.

footnotes and airplanes

love this explanation of the importance of specifications - from joel spolsky in a salon.com interview*

The fundamental problem that you're trying to solve here is that humans think of things in vague, mushy terms. In order to visualize something, they don't have to actually visualize every part of it. Whereas the programmer, in order to actually implement that thing, to create it, needs to have every part specified. So you can imagine an airplane without even knowing what a rudder is, yet without a rudder an airplane's not going to work very well. Partially that's just the way the brain works. …

…One of the biggest mistakes you can make in developing software is to say, "I'm going to build this thing and it's going to be super easy to use because it's going to be super simple, it's going to be unbelievably simple." And then you say, "OK, how am I going to do footnotes?" Oh, well that'll be real simple -- you just ask for a footnote and you type a footnote, and it'll just be there. Well, what if the footnote is too long to fit on the page it's currently on? Um, I don't know -- maybe you have to move part of the footnote onto the next page. Suddenly, it's not so simple.

As soon as you start to think about how to get everything to really, really, really, really, REALLY work, it becomes much more complicated. So software starts out with a simple vision and it grows a million little hairy messy things. And depending on the quality of the initial vision, those hairy things may be more or less hairy, but they're going to exist.

And therefore, because software seems so simple and is actually complicated, you can't implement it until you specify the complication. And all these people that are trying to make the same perpetual-motion machine -- where you just write your specification and it automatically becomes code -- don't realize that the specification has to be as detailed as the code in order to work. …

…And so what a programmer is doing when they translate a quote unquote spec into quote unquote code, although it seems like a translation process, what they're actually doing is filling in lots and lots of details. And as programmers are wont to do, they're trying to take something, the vague thing that the humans want, and make it very, very specific, which is the kind of thing the computer wants. That's not really a translation; it's more of an interpretation. It's a very hard thing to do.

The perpetual-motion machine is where you say, let's just take these business requirements that some business guy came up with and suddenly, instantly make code from them. And that doesn't work, because the business requirements don't actually specify what to do with the footnotes when they run off the bottom of the page. And the computer's going to have to know.

and this bit on web vs. desktop apps:

There's a couple of other issues which would be nice to solve. One is to give you a way to work offline in limited circumstances. Let's say you wanted to make Gmail, but Gmail where you could actually take it on a plane and work offline, read your e-mail and send e-mail, queue it up for delivery. And so somebody could develop some kind of standardized system for doing that kind of offline work.

Adam Bosworth has been working on this a lot -- we'll see if anything comes out of that, now that he's at Google. That would be cool. But the funny thing is, Bosworth has been talking about this same problem for a long time -- he's just obsessed with the person on the airplane. And, lo and behold, airplanes are actually getting Internet connections. And Wi-Fi is spreading like crazy. What's kind of surprising is that it has turned out to be easier to rewire the entire world for high-bandwidth Internet than it is to make a good replication architecture so you can work disconnected! It's actually far more likely that this problem will be solved that way, oddly enough.

* subscription or free day pass (watch an ad) required.

css & ia

Nate Koechley and Christina Wodtke's IA and CSS presentation delivered at webvisions2004.

naked objects

Naked Objects Framework, available as an open or commercial license, is an approach to designing and developing business systems.

The 'naked objects approach' is a radical approach to the design and development of business systems, which yields four benefits (presented below). The 'objects' represent the domain entities of the business, such as Customer, Product and Order. In conventional approaches to business systems design (the left hand side of the graphic below), these business domain objects are masked from the user by two intervening layers: a 'presentation' layer that manages the user interface and a 'controller' or 'application' layer (sometimes also called the 'process' or 'task' layer) that defines all the possible user tasks and scripts the interaction between the user interface and the underlying objects. Below the domain layer is a persistence layer, which is most commonly based on a relational database. Writing a business application implies not only writing all four layers, but also translating the requirements from the user presentation into the different representations used in each layer. And the same effort is involved for each subsequent change in requirements.

great hackers

newest essay from Paul Graham - Great Hackers

In programming, as in many fields, the hard part isn't solving problems, but deciding what problems to solve. Imagination is hard to measure, but in practice it dominates the kind of productivity that's measured in lines of code.

variation among programmers is huge:

Ordinary programmers write code to pay the bills. Great hackers think of it as something they do for fun, and which they're delighted to find people will pay them for.

so what do they want from their jobs?

good tools, it's a social decision as well as techical one:

But a programming language isn't just a format. A programming language is a medium of expression.

control

Great hackers also generally insist on using open source software. Not just because it's better, but because it gives them more control. Good hackers insist on control. This is part of what makes them good hackers: when something's broken, they need to fix it. You want them to feel this way about the software they're writing for you. You shouldn't be surprised when they feel the same way about the operating system.

good environment

If companies want hackers to be productive, they should look at what they do at home. At home, hackers can arrange things themselves so they can get the most done. And when they work at home, hackers don't work in noisy, open spaces; they work rooms with doors. They work in cosy, neighborhoody places with people around and somewhere to walk when they need to mull something over, instead of in glass boxes set in acres of parking lots. They have a sofa they can take a nap on when they feel tired, instead of sitting in a coma at their desk, pretending to work. There's no crew of people with vacuum cleaners that roars through every evening during the prime hacking hours. There are no meetings or, God forbid, corporate retreats or team-building exercises.

interesting work

…a good manager can sometimes redefine a problem as a more interesting one. Steve Jobs seems to be particularly good at this, in part simply by having high standards. There were a lot of small, inexpensive computers before the Mac. He redefined the problem as: make one that's beautiful. And that probably drove the developers harder than any carrot or stick could.

managers with good taste :)

There's no way around it: you can't manage a process intended to produce beautiful things without knowing what beautiful is. American cars are ugly because American car companies are run by people with bad taste.

Many people in this country think of taste as something elusive, or even frivolous. It is neither. To drive design, a manager must be the most demanding user of a company's products. And if you have really good taste, you can, as Steve Jobs does, make satisfying you the kind of problem that good people like to work on.

What VCs should be looking for is the next Apple, or the next Google.

I think Bill Gates knows this. What worries him about Google is not the power of their brand, but the fact that they have better hackers.

what makes a great hacker?

The best hackers tend to be smart, of course, but that's true in a lot of fields. Is there some quality that's unique to hackers? I asked some friends, and the number one thing they mentioned was curiosity. I'd always supposed that all smart people were curious; that curiosity was simply the first derivative of knowledge. But apparently hackers are particularly curious, especially about how things work. That makes sense, because programs are in effect giant descriptions of how things work.

(via sporter)