(Part 1 of 2)
Let's cut the to chase: The web is a 1960's era IBM mainframe, and it sucks.
Mainframe interfaces are characterized by a query-response mechanism. Your terminal requests a starting point and a screen is sent to your terminal — the terminal being your remote interface to the computer. You read the screen, enter data in a few fields, then send the screen back to the mainframe. The mainframe processes it, then sends you a new screen. Lather, rinse, repeat. It was little more than a paper-based system running at 300 baud.
By the 1970's, the minicomputer, pioneered in the marketplace by DEC, had changed the face of computing by selling computers with interactive terminals. Instead of exchanging screens, the user's terminal was an actual process on the minicomputer. It was still limited to text (for the most part), but you had a realtime access to the computing resources. This turned out to be a profound change. Instead of filling out forms, submitting them to "the office", and waiting for a response, you actually manipulated data directly. The paper-style interface was replaced with fast command/response cycles, enabling users to work more quickly and flexibly. Interactivity at 9600 baud.
By the 1980's, personal computers had appeared on the scene. Like the much more expensive minicomputers, they had interactive text interfaces. Unlike the minicomputers, 100% of their capacity was devoted to one user. You worked directly with the data — a first, outside the halls of academia and obscure corporate research facilities. And for the past two decades, we have worked with data ever more directly and intimately. Personal empowerment as fast as your hard drive can spin.
Then the web came along. You start by opening a terminal — although we call it a "web browser" now. It opens a "home page". You read the screen, maybe type in a few web form fields, then click "submit" or click a link. The request is sent back to the web server. The web server processes it, then sends you a new screen. Lather, rinse, repeat. It's little more than a paper-based system running over a T1.
It's a very fancy mainframe terminal. It has colors and pictures and different typefaces, and sounds, and rollover effects, and Flash geegaws and doodads, and all of that fools us into thinking we're looking at an interactive system. But we're not. We're looking at a forty year old mainframe interface that's been worked over by a graphic designer with an XGA screen.
The web sucks. Down with the web.
(Coming real soon now: Part 2)
A couple weeks ago, Dave wrote a blog about the importance of project planning, and I still agree that planning is an important part of the process, I now also know something equally as important: communication.
Without communication, all is lost. In fact planning isn't effectively possible without communication. For example, someone on the sales team could plan out a complete site for a client without talking to them, the designers, the devleopers, the project managers, or anyone. While they may come up with what seems to be a great idea that attempts to take everyone into consideration, ultimately details will be missed.
How do you know what the client wants?A lack of communication undermines the process of planning. Does this make it more important? I originally thought yes, but you can communicate without having a plan and come in equally off base, so it seems not. They appear to be equally important.
Is this possible, is that possible?
Do we have the time and resources for this schedule?
Can the client come close to even affording any of this?
Are there any easier and better ways to do this?
Does this page need content?
Should this be dynamic or static?
There are many ways to increase communication within your team. Depending on the size of the team there are many solutions out there to help you. A lot of people recommend 37Signals' Basecamp for project management. I checked it out this weekend, and while I didn't actually use it with a project, it wasn't anything like I was expecting. I've always heard 37Signals refer to themselves as giving you nice and simple tools, but it wasn't that simple. (In fact, there was so much reading on each page that I quickly grew bored and gave up.) Decent attempt, poor implementation.
Here at iMarc we have a wiki that is great for sharing ideas, keeping a central location for our thoughts, to-do lists, schedules how-to's and plans. There are limitations, however, and while wikis are good because they are open, they're not really geared towards managing multiple projects.
Microsoft Project was a program we had to learn while in school. Again, while this seemed to manage things nicely, it was overly complicated.
I've yet to find a simple, straight-forward solution for this, but I digress.
A lack of communication causes the decay, deterioration or destruction of timelines, and can be considered the root of 90% of the problems one will find in any team project. The flow must be open and honest, with everyone being on the same page at all times. Frequent quick, regular meetings with your teammates are just one of the many ways to ensure that things are getting done on time and on budget (the two more important 'ons' of the business world).
The success of your project depends on it.
If you've been following the iMarc blog (not iMac, mea culpa), you may have noticed that we hate Comic Sans. It couldn't possibly have been meant as a serious, real typeface, could it? It's awful. Who would do that on purpose?
Turns out it was all an accident. Sorta. See Vincent Connare's write-up of why he created Comic Sans, and why it's part of Windows now.
(Credit for spotting this goes to Fred. Thanks, Fred!)
But, contrary to popular opinion, Comic Sans does have a purpose. One of our developers uses it on a hideous green background as his default browser text style. Why? Because it ensures that he'll never, ever forget to apply proper page styling to anything he's working on. The mistake would just be too painful...
iMarc recently completed a web site for Wolf & Company, Certified Public Accountants & Business Consultants. With a century-long history of service, it was important to Wolf to show their community heiritage side-by-side with their wide range of expertise. Since staff recruitment and retention is key to a service-based company such as Wolf, the site also showcases career opportunities and growth potential.
Of course, the site has to be easy to maintain and keep fresh. So iMarc built easy-to-use content management tools, that make publishing content fast and easy, and ensures that new content is attractive and complies with the company style guidelines.
"iMarc delivered on our project needs and objectives! And throughout the development process, iMarc was professional and efficient. In addition to the inviting new look and feel and user-friendly navigation, our new site allows us the flexibility to easily administer a variety of content updates ourselves without creating a drain on staff resources or investing in monthly maintenance fees."
— Margery L Piercey, CPA, Principal
Wolf & Company, P.C.
Certified Public Accountants & Business Consultants
The site architecture is built on a dynamic, database-driven framework that makes it easy to add, edit and remove pages from the site. At the same time, the architecture preserves branding and navigation across all pages, so contributions to the site contain appropriate branding and formatting. This means the site can grow, without redesign costs, to satisfy Wolf's needs for years to come.
About Wolf & Company
Wolf & Company, P.C. is a certified public accounting and business consulting firm with offices in Boston and Springfield, Massachusetts. As a leading regional firm founded in 1911, Wolf provides its clients with comprehensive audit, tax and risk management services delivering extensive resources, specialized industry expertise and outstanding service.
Visit Wolf's web site at www.wolfandco.com.
All of our dynamic sites come with their own online tool-kit that we call the "admin area" to help maintain your site and keep things fresh. Elements of a site are controlled dynamically from here, which enables you to keep your site up-to-date from anywhere in the world (which, as we all know is the full glory of the online life).
While the admin area never gets displayed to the public, its importance rivals that of the full-package of the public display. Many times this is like building two separate sites as one package, but the end result is well worth it.
Why? A couple of reasons.
First, a lot of clients will look at their admin area just as much (if not more) than the public side of their site. They should visit the admin area regularly to ensure that information is as current and valid as possible. This area should be easy to use, simple to figure out and well organized.
Second, this is what represents us (iMarc) on a regular basis to the client. When they visit their admin area, they should see us and our principals in the work we've done. (After all, if the admin area is amazing, just think of how good the front-end is.)
Third, while this reminds the client of us, it doesn't require the client to have to contact us. Don't get me wrong, we enjoy talking with our clients and don't mind helping them out, but a well-made admin area is easy enough for anyone to figure out. This also comes in handy when whoever is maintaining the Website moves on to other parts of the company and has to train someone else on how to use it.
This brings us to a theory not used enough on the Web these days: Occam's Razor. It is a principle that states "given two equally predictive theories, choose the simpler" (Wikipedia: Occam's Razor). This doesn't exactly fit here, but we can go a step further and say if two processes acheive the same goals, the simpler is preferred. (And as argued by Dave, if it's preferred, it must be better.)
In a lot of the things that we do in our day-to-day lives, one tool that can do many things (corporate buzzword "multitask") is better. Why have many remotes for many appliances when you can have one remote to control everything. This converence of technologies was thought to be the wave of the future at one point, and I suppose to a degree still is, but there have been noticable walls where such is not the case; take for example the Motorola ROKR, combining MP3 playing with a phone just never was really that appealing to the mass audience.
But I digress. While convergence may appear to make things simpler, it infact complicates the entire process. Two simple tools combined into one supertool creates the weird gateway between them in which they must interact, convoluting code and logic.
This is also something that must be watched in creating our admin tools. There have been times in the past where we have created one tool that actually manages many different aspects of the site (and sometimes multiple sites) with one form. Combining many ideas into one tool ends up in confusion and explanation.
Which brings me to my main point: the 1 Tool 1 Task initiative. Each tool in an admin area should serve to maintain one and only one aspect of a site. As an example: we may have a section called "News & Events," but I wouldn't expect to see a "News & Events" tool on the backend of a site if they contain different data. I would expect a "News Manager" and an "Event Manager," because although they're being displayed on the same page, most of the time these things feature completely different data. (In the case that these display the exact same data, combining them is possible, but it's still logically simpler to handle two tools.)
For a lot of our tools, there does seem to be a number of tools that have similar schema, but there is not a skeleton key to control them all, nor should there be. That's the reason we offer custom solutions to each of our clients instead of a Web tool to fix the current problems. Furthermore, I'd rather spend the time creating two separate tools instead of having to hack through the thinking to stuff it all into one. It's the better use of everyone's time (or 'money' on the client end of things, since time = money).
This can lead to one site having many tools, and while it sounds like it might be overwhelming it truly isn't. Check out this picture of what the Springfield Museums admin area looks like. Nice icons, simple layout, very easy to use. A lot of these tools look very similar, but we've broken them out into logical tools, and so far we haven't heard any complaints. (Additionally, this site is updated more often than a lot of the sites we've built due to its size. I wonder if these are related.)
As you can see, simple doesn't equal less. Simple means easier to understand, which in some cases (like this) means a little more work. Either way, the end product is worth it.
This may end up being just one of the many battles I'll be fighting alone around the Web, but it's a worthwhile cause.
1 Tool 1 Task
To the right is a screen shot of the extension in action after requesting http://www.google.com. As you can see, it displays all of the http headers including cookies. The extension is easily activated by pressing Alt-L (on Windows, not sure on OSX) and can even save headers to disk.
For everyone upgrading from Firefox 1.0.7 to Firefox 1.5, make sure you get the new version, 0.11. You can download it from the LiveHTTPHeaders site, or from http://ftp.rz.tu-bs.de/. I wasn't able to get the version on the official site to work, so I grabbed it from the ftp server. Enjoy!