Wednesday, December 14, 2005

A Quick Word on User-Interface Design

Excellent user-interface design isn't that complicated. It is not my intent to take anything away from experts in this field with their HCI, human factors, cognitive psychology, etc. degrees, I simply don't think it takes a PhD to design usable sites and web-based interfaces.

As someone who has evangelized user-centered design and web accessibility good user-interface design has simply been a must. It doesn't matter what functions the web-based service has or how robust the data is if the user can not intuitively use it. Bottom-line: if the user can't use it, it's useless.

Now on the web this become tricky as you have a single user-interface that every end-user group with their individual thought process must use. By simply understanding your users (who they are and what they are there to do) and understanding some basic and fundamental online behaviors patterns and theoretical UI and design principles a sound and usable site design can be obtained. Then by running this design through some usability workshops the subtle nuances should be vetted and a web-UI with strong visual hierarchy and an intuitive navigation system arrived at.

UI Before/After Samples

Friday, November 25, 2005

Data Aggregation for Integration of Web Services

Web services integration is not about centralizing services. Rather it is about building upon standards and open-source technologies so that businesses and institutes can benefit from web-based services and incur on-going long-term cost-savings.

This approach not only addresses fiscal concerns it also mitigates concerns over ownership of data. By pulling all data from the authoritative database and creating a standardized well architected data warehouse the data can be used and shared by various web-based applications while allowing the ownership and data maintenance to remain distributed.

In addition to developing the standardized data warehouse building on a XSLT/XML framework further allows content to be developed (inputted) once and published everywhere. Not only can the content be called by external company/institute sites managers, who can then apply their own style sheet so that the data appears to be local content, it can by syndicated via RSS and subscribed to by users. Once a RSS/XML feed is established aggregating data for purposes such as an enterprise-wide web portal with single sign-on can be easily facilitated.


The SJSU Approach to Data Warehousing Distributed Databases
for Integration of Web Services


Download Integrated Data Schematic

Podcasting in Higher Education

from edublogs

It features interviews from Duke University, where the Duke iPod project was launched in 2004 to measure their use in a Higher Ed setting. I began to get excited: an inside view on the Duke project, about which I had heard some negative...

Read more...

University Weblogging: Where, With What System (and How Fast)?

A post from Spike Hall's RU Weblog [blog]

Wikis as Higher Educational Tools: Some Links and Arguments

A post from Spike Hall's RU Weblog [blog]

Web Portals and Higher Education

Another excellent eBook from Educause [www]

Open-Source in Higher Education

Report on the use of open-source technologies in higher education. [pdf]

Thursday, November 24, 2005

Approaching HigherEdWeb

[taken from my portfolio]

Having performed work for non-profits, student organizations, universities, professional sport teams, politicians and exotic dancers and worked with large design firms such as Razorfish I have refined my workflow process so that it can be used for various clients with numerous stakeholders. I have also had the unique opportunity to see first-hand where lessons learned from one industry can be applied to another.

The ability to amalgamate these lessons and experiences to the tangible benefit of a web project is ultimately enhanced by adhering to a design philosophy that embraces standards such as XHTML, XSLT and XML and building upon open-source solutions. In taking such an approach to designing and developing for the web the final work product is assured to be both sustainable and extensible.

As a university webmaster for two of the larger campuses in the California State University system it has become quite apparent that one can not take lessons learned from e-commerce and web services from the private sector and apply them directly to higher ed. When it comes to web sites for institutes of higher education most of us in this niche of the industry are shooting into the dark. Although we have a good idea of what is needed, how can we be sure that we are on the right track. When you consider the digital divide that exits between university administrators and the millennials (net generation) this question becomes even more daunting. Of course we can look at trends in website development in general and infer where we should go but how smart, in terms of a business model, is this approach?

My primary objective as a web technology strategist is to address not only this technical divide but to also leverage the power of the internet and the benefit of web standards so that ownership can not only remain distributed but so that data can also be used by all while being pulled from the authoritative sources. In addition, integrating web services (this is not the same as centralizing) should allow the institute to streamline business process and customer service while resulting in enterprise-wide cost-savings.

Surprisingly this approach to web-based services is a new model for higher education. Add to this model a user-centered design approach that results in an excellent user-interface and the final product will not only be simple and intuitive to use but will also meet the identified business objectives and exceed overall expectations.

Technology can not be used only as a tool. Rather it needs to be part of our lifestyle. Once we arrive at this point it will no longer be "technology."

Monday, November 14, 2005

My del.icio.us bookmarks

These are virtually all relevant to higheredwebs http://del.icio.us/nozicka

Wednesday, August 17, 2005

HighEdWebDev Conference

I recently came across a conference that appears to be appropriately designed for our specific niche of the websphere. I am planning on attending but was wondering if any one has attended this conference in the past and if so what their thoughts were about it.

---------------------------------------------------------------------------------------

This year marks the tenth conference for the WebdevShare Program Committee and the second year WebdevShare and HighEdWeb have worked together to present our new conference, HighEdWebDev. We are proud to present this annual, international conference aimed specifically at higher education Web professionals. Join us November 6 – 9 at the RIT Inn & Conference Center in Rochester, NY.

Conference Website: HighEdWebDevo5

Thursday, June 09, 2005

Feature vs. Function

When it comes to the design of what people use there are many variables that must be considered. If you were to ask some one what they thought were some of the most important things to consider you would get answers like ‘the ability to do this,’ or ‘capable of such-and-such,’ or ‘I want to be able to…’

Often times these are referred to as the “functionality” of the product. However, this is an erroneous label as these are actually “capability features”. One may consider the difference between the two to be purely a matter of semantics but it is much more. The difference between what is a function and what is a feature can even be considered a philosophical debate.

Let’s forego the philosophical aspect at this time and simply consider a couple of scenarios. First, let’s look at the automobile. Specifically, let’s look at an automobiles ability to stop. This feature (the ability to stop) is agreeably important, thus, all automobiles must have this feature or we would all be living in Bedrock stopping our cars like the Flintstones. Now, if we analyze how the braking feature functions this is a completely different set of considerations. Brakes are activated via a pedal. Why? Because, requiring the driving to say, open the glove compartment and depress a red button to stop the car, isn’t that usable. In fact, it’s a liability. A pedal simply makes sense because based on how a driver operates (uses) a car activating the braking mechanism via a pedal requires the least amount of effort (and thought) while providing the greatest amount of functionality (usability).

The second scenario to consider is how a house in constructed. Houses built properly utilize a team of experts. From architects, designers, general contractors, construction workers, plumbers, electricians, painters, landscapers, etc. Why? Because we have evolved into a society of experts and by using a team of experts the sum of their collective knowledge results in a final product that meets all requirements, user desires, legal requirements/regulations, etc. and ultimately exceeds all expectations.

Imagine what would happen if a plumber attempted to perform the work that the electrician should be performing or an architect drew up plans for a construction worker that didn’t meet OSHA standards. The final product would be deficient. Not only would it not meet legal requirements, it would not meet the home owner’s needs and would therefore be unusable.

Features are a product’s capabilities and must meet user requirements, resource limitations and business objectives. Functionality on the other hand, is how these features are actually implemented.

The Web has evolved to a point of maturity where not only are there industry standards (adopted by manufacturers and followed by designers and developers), but there are also specialists – experts in the various areas of web design and development. The presence of specialized roles isn’t really something that resulted from the big bang (and bust) of the web. It isn’t something new. It has been adopted from software engineering.

There is a distinct difference between a designer and a developer as it applies to human-computer interfaces. The developer is the person who codes, they are the programmers. Then there are the designers, the people who make things look pretty. There is also a third role – the information architect. This is the person who must understand end-user behavior patterns and things like usability and accessibility. This is the person who must ensure that a site’s (web application or web-based service) features are as easy to use (function) as possible.

It should not be up to the developer to decide how to implement a feature. This should be defined by the information architect and then built to spec by the developer. It is very easy to see the various sites that run the vast spectrum from designer-built to developer-built. Sites built by a designer tend to be extremely aesthetically pleasing, but lacking in overall features (or the features implemented are not based on direct end-user needs). Sites built by a developer tend to be rich in features, but difficult to use for end-users. Sites built from either end of the continuum are deficient and ultimately unusable.

In comes the information architect. The information architect will take the UI from the designer and review it to ensure that the proper visual hierarchy is obtained, that the design can be implemented (and where modifications need to be made), and that usability and accessibility concerns are addressed. This same person will then work with the developers to spec out how the features will be implemented so that they afford the most functionality.

The design and development process for web-based user interfaces has matured but it is also cyclic in nature. The goal of the initial launch of a web-based service or site is to maximize the amount of time between go-live and the next version. In order to do so all things must be properly considered and industry niche experts properly utilized. By doing so usability and accessibility concerns will be minimized and functionality maximized thereby minimizing the necessity of working on “fixes.”

When decisions need to be made proper time and due diligence should be given to what is in the end-users best interest. Trade-offs in the interest of budgets or resources should never be made at the expense of the end-user. The bottom-line is that if the product doesn’t meet the end-users needs and work in way the end-user expects, it is a failed product. The number of features a product has is ultimately a moot point if the end-user doesn’t, won’t, or can’t use them.

Additionally, if for all intent and purposes said product (that is deficient in usability) is the only one available for users the result will be in elevated costs across the board for the institution. These avoidable costs will come in the way of customer service and support (ie. helpdesk) and in the need to redevelop shortly after launch to address usability issues and product deficiencies. Unfortunately, all too often people don’t take the time to do things properly the first time. In essence it appears that they don’t have the time (resources) to do things right the first time; yet, they always seem to find both when things have to be done a second time.

There are two things that greatly increase the chance of having a successful web-based product to launch. The first is the use of user-profiles. A fictitious (and well-thought out) user profile should be created for each identified end-user segment. These user-profiles will enable the team to ask how said user would use the system rather than asking the team to attempt to conceptualize how they think a user would use it.

Second and probably more important is usability testing. This is not the same as beta testing. Usability testing involves users from the various identified end-user segments and who are not involved with the project. Usability testing should occur at various points during the product development process to ensure that things are being built properly to meet end-user needs. Studies have shown that a single usability test with as few as three users can identify 80% of usability issues.

Frankly, quite often the way that results in the most effort and time from the development and design team will be the solution that works best for the user. In some ways this is simple logic. The more time taken to properly develop and implement functionality the less effort that will be required on the part of the end-user when they actually use the system.

Friday, April 15, 2005

Why XHTML with CSS matters

From you can sleep when you're dead

The IE/Netscape browser war is over, and most web users are using standards-compliant browsers like Firefox, Safari, and IE 6. The old table-based layout techniques are no longer necessary.

Read more...

The Music of Wireframes

From UXCentric

Think about it. A score isn't music, just as a wireframe isn't a Web page. A score tells the musician what notes to play, when to play them, how to play them. A wireframe tells the project team what content to include, its placement and how it behaves.

Read more...