vanderwal.net

Joel explains the software development paradox when the technical folks and non-technical folks meet. I am very fortunate that I do not go through this at the moment, as I work for a client that understands the development process. I can not say that about every place I have been, but the developing a prototype in a few weeks that has rough functionality in it is light years from an actual product. The most important part of that next step is getting real data and getting a good understanding of the data and information you are working with as well as knowing what is to be done with said information. This being said is why many of us like using wireframes for interface development and not live GUIs (there are other reasons to use wireframes, but I will address that on another day, possibly real soon).

In following the ArsDigita closure, I have found many linking to a diary of a start-up, or how ArsDigita began. The goals and inspiration for the company are a place that many would want to work. Remembering back there seemed to me many places that had high-minded goals, but lost sight when money came in. Philip Greenspun also offers his take, which includes a great insight...

Spending time in the aviation world has given rise to some thoughts about why there are so few plane crashes and so many business failures. The FAA establishes strict guidelines on what training and experience is required before someone can be pilot-in-command in various situations (daytime, nighttime, instrument conditions, single engine, multiengine, turbine, all alone, one passenger, lots of passengers, etc.). The president of United Airlines can't hire his old college buddy and put him behind the yoke of a 747 because he has a good gut feeling that Biff can handle the job. Very seldom is a pilot legally able to get into a situation that is beyond his or her capabilities, training, and experience (JFK, Jr., for example, was flying in instrument meteorological conditions with only a visual flight rules rating; he was legally required to make an immediate U-turn and fly back into the clear). But in the business world the Peter Principle rules: people are promoted until they reach a job at their level of incompetence. Because there are no standards, it really isn't possible to say whether a person is unfit for a business job until and unless you give him or her the job. Afterwards it is tough to admit that you made a mistake and demote or fire the incompetent-at-that-level person.

This is very much a meritocracy mindset, which a lot of us that are in techinical fields hold to be true.

Arg. If you have Internet work and need somebody great, I know of a great developer looking for work. Send Nick your leads and best wishes.

Okay, O'Reilly Net has been offering a lot of good resources of late and I am a little behind in catching up.

Those of us that need a light weight database for a small project and are using Microsoft Windows often turn to Access to perform the task. Steven Roman offers his tips in how to set up an Access database. The best tip is right up front:

Don't touch your PC until you have taken the time to rough out a design of your database.

The tips keep coming and many of them apply to any other database development. Once I learned to think of information and metadata in a relational database format (which also helps with setting up XML documents) application development became easier. Understanding a little database design will also help ask the right questions when setting up an application, database, and/or project.

This article also helps define the limitations of Access databases. Each database will have its own limitations or peculiarities. Knowing these differences will help think about the application, information, and how they can and will be used is helpful.

Do you build Web pages? Do you have Mac? Do you have to convert text to HTML/XHTML? If you answered yes (if you didn't you should see what you are missing) please go check out Dean Allen's AppleScript for writing on the Web. These should be wonderful additions to our tool belt.

Peter Morville provides Innovative Architecture that looks at the future of IA, which incorporates collaborative IA. The users of many sites create or hone the IA through many components, such as Amazon's "people who bought this item also bought." I like the breadth of this piece and how it encompasses applications and community driving IA.

Matt makes observations of the state of severs and scripting deployments. I agree with nearly all of what Matt point out. Some of the reasoning behind the varying set-ups is for security reason's, others are to mirror configurations on other servers that had slightly different purposes. In all, what this needs is a solid documentation tool. PHP provides some of this with a function that prints out the build of the server that script resides on, this is usually the first task many of us perform on a machine. This however, is just the tip of the iceberg of the information we need.

This is part of the second and fourth element of the cornerstones of information application development (info apps need to be usable, maintainable, reliable, and repeatable). If a task is difficult to maintain and even harder to repeat there is some work that needs to be done to change the environment or the application.

Content management is back at the forefront of every aspect of my digital life again. Content management revolves around keeping information current, accurate, and reusable (there are many more elements, but these cut to the core of many issues). Maintaining Websites and providing information resources on the broader Internet have revolved around static Web pages or information stored in MS Word, PDF files, etc. Content management has been a painful task of keeping this information current and accurate across all these various input and output platforms. This brings us to content management systems (CMS).

As I pointed to earlier, there are good resources for getting and understanding CMS and how our roles change when we implement a CMS. Important to understanding is the separation of content (data and information), from the presentation (layout and style), and from the application (PDF, Web page, MS Word document, etc.). This requires an input mechanism, usually a form that captures the information and places it in is data/information store, which may be a database, XML document, or a combination of these. This also provides for a workflow process that involved proofing and editing the information along with versioning the information.

Key to the CMS is separation of content, which means there needs to be a way to be a method of keeping links aside from the input flow. Mark Baker provides a great article, What Does Your Content Management System Call This Guy about how to handle links. Links are an element that separates the CMS-lite tools (Blogger, Movable Type, etc.) from more robust CMS (other elements of difference are more expansive workflow, metadata capturing, and content type handling (images, PDF, etc. and their related metadata needs)). Links in many older systems, often used for newspaper and magazine publications (New York Times and San Francisco Chronicle) placed their links outside of the body of the article. The external linking provided an easy method of providing link management that helps ensure there are no broken links (if an external site changes the location (URL) it there really should only be one place that we have to modify that link, searching every page looking for links to replace). The method in the Baker article outlines how many current systems provide this same service, which is similar to Wiki Wiki's approach. The Baker outlined method also will benefit greatly from all of the Information Architecture work you have done to capture classifications of information and metadata types (IA is a needed and required part of nearly every development process).

What this gets us is content that we can easily output to a Web site in HTML/XHTML in a template that meets all accessibility requirements, ensures quality assurance has been performed, and provides a consistent presentation of information. The same information can be output in a more simple presentation template for handheld devices (AvantGo for example) or WML for WAP. The same information can be provided in an XML document, such as RSS, which provides others access to information more easily. The same information can be output to a template that is stored in PDF that is then sent to a printer to output in a newsletter or the PDF distributed for the users to print out on their own. The technologies for information presentation are ever changing and CMS allows us to easily keep up with these changes and output the information in the "latest and greatest", while still being able to provide information to those using older technologies.

Troy Janish's XML tutorial for A List Apart is a great resource. The elements for implementing XML are rather solid now. Knowing how to make use of XML is going to be a needed skill set for many. The debate over database storage of content objects over XML storage of the same will continue for quite some time. I have my leaning for database storage, given their data storage and manipulation functionality built in, but outputing XML documents to share the information seems to be a better option than providing authorized access to the database.

Stewart mulls the positive feedback loop in interaction design in his weblog. Stewart also links to a nice report/bulletin article highlighting designers of the future (kids) for SIGCHI Bulletin.

Stewarts article brings to mind the problems with capturing process and tasks when observing users perform their jobs in the early stages of contextual design. The last thing the observer wants to do is to influence what the user is doing. Asking questions on how to improve and working through the logic of the tasks and conditional elements of the task will come later. Understand the conditions the user has in place, don't ask why at the beginning, just capture as if you were going to have to repeat the exact same task.

The next step after capturing the information allows for understanding why there is a "wrk" button (using Stewart's example). Understanding what is behind the conditions will help build an application that is used as it maps to the user's cognitive understanding of the process. Some of these conditions may/can be broken when they are built into an algorithm. Breaking too many of the conditions can create an application that is quite foreign to the user and therefore possibly shunned.

One method of getting through the non-essential conditions is to use a transitional process. This would entail keeping some of the non-essential conditions in an applications interactive process with the user, i.e. sending an e-mailing to verify a fax was received. Including a verification notification for delivery of information may be included as it is engrained in the user's work pattern. As the user's learn to trust and respect the information in the new application they are using is reliable the verification notice may be altered to show only information not delivered or turned off completely.

Getting back to the starting point, if an observer would propose turning off the verification process and notification in the task capturing procedure there may be one individual that understands why there is not a verification process. The application being developed may be for many users that use the standard procedures. The user being observed may offer suggestions and these should be captured.

Grokdotcom provides a good overview of the methodologies of Web application development. The modular approach is provided as the best methodology, go figure with an open methodology that is based on published/documented standard set of processes. The article ends up discussing Fusebox, which is new to me, but seems to be a rather straightforward approach to modular software development.

An USA Today article on poor product design provides insight that is helpful not only to product development, but also application development. The insights (while not new to most of us, but most likely very new to USA Today readers) include not including the consumer early enough in the process, product design team not well balanced, and technology runs amok.

These very closely apply to Web/Internet/Application development's downfalls. Not including the user in the development phases and/or testing with users early and throughout the development process. Having a development team that does not have a balance of visual, technical, and production skills can be problematic. Lastly, projects that are technology for technology's sake, very rarely offer success.

Conversely, success comes from getting these things right, involving the user and understanding how users would interact and use what you are building. Having a balanced team so that visual, technical, and production issues can be addressed and solved appropriately. And lastly knowing when and how to best use what technologies will drive success.

This last element, understanding the technologies, will help you get over the hurdle of accessibility/508 compliance. It will also help you find the best tools to interact with the users of the site/application. Having DHTML elements to provide action on a site or to serve information, when the user audience does not fully have the capability of addressing or handling the presentation, will have detrimental effects. Know what your elements your users have turned on and off in their browsers and what versions they are using. It is important to know what threshold of user profile can be the cut-off for developing a site. If 10% of your users have JavaScript turned off should you still develop elements of your site that are JavaScript dependant without providing an alternate service? Know and set this percentage threshold, as it will help understand why you can and can not use certain technologies.

Google shares its 10 things they found to be true, which starts off with, "focus on the user and all else will follow". There are many other truths in this list. [hat tip eleganthack and Digital-Web New]

There is nothing like starting the New Year coding a time rollover code to pull the current information out of your weblog. This means I now have fully functioning code for month and year change overs in my personally built weblog tool. This also means I still love PHP more than any other scritping/Web coding language.

It is getting to be time to pull the code out of the PHP templates and make it more modular/object based. The site is built on a handful of templates that reuse about 75% of the same code to build the pages. From this stage it is time to pull out classes and functions and have each page point to the proper elements. This enables me (or who everelse is getting this code) to be able to make modifications in one place rather than many.

Why modular/object-based? This is how the world works. This is how things are done efficiently. This is the non-foolish way of building applications. (Looks like I am starting this year on a testy note).

The Way We Webbed

Builder.com to focus more on technology than Web. This article, delivered to my e-mail a couple weeks ago, has been ringing in my head. The Web is not dead, but how it is build has changed greatly. All of have learned a lot over the past few years and we all have grown greatly. Many of us have been implementing content management systems or rolling our own solutions to ease the management of these sites. We have build community tools and become readers and commentors on other's sites.

The Web is no longer just static pages. It has not been for some time. Dynamic pages have there limits too and we all have found wonderful balances to build a better Web that is a better tool and information source for the users. The Web has also burst its seams and spread back out over the broad Internet. The Internet has become mobile and Web content has been repurposed and is now showing up on handheld devices and developers are creating versions of their information to ease this adoption (this will be an addition to this site in the next month or two, so to accommodate those that read this site on wireless AvantGo readers). Information is also syndicated using XML (RSS) so others can pull the information and use it in a manner that best suits them.

There will be a need for Web pages for quite some time. The great skill of Web design (from folks like Jeffery) will continue to be a needed profession as the design and visual presentation of information is essential to better understanding of the information and eases the adoption/internalization of information. I look forward to the new content from Builder.com, but I also will miss some of their focus too.