Real World DotNetNuke Part III

I don't believe I've seen you here before. You may want to subscribe to my feed to keep informed of new posts at DynamicVB.NetRSS feed. Thanks for stopping by!

The last iteration of Dwayne’s assessment of Real World DotNetNuke and its uses in the business of providing web hosting and application functionality in the pursuit of making money in business today. To me this is the most important of his posts as it addresses the needs of developers to understand that functional performance is just not enough. For users to accept a application, then it must look good and be easy to navigate or they will just give up before they can learn the cool functionality it offers.

The user interface is one of the most important aspects of any development project. A user decides quickly whether your application is useable or not, regardless of what it “can do”. If the user interface is clunky or confusing, most people will move on to an alternative solution even without the bells and whistles. Their job is to perform tasks, your job is to make it easy to perform these tasks

Developers are a rare breed and they tend to concentrate on how things work, rather than how to work things. Sure DotNetNuke gives you this wonderful framework to allow users to edit text from their browser, but anyone who has spent considerable time constructing a beautiful page knows how frustrating it is when they happen to click on the page and hit the backspace button. Or the back button on the keyboard, or the little back button on the side of the mouse. You have just lost all of your work!

How productive is this serious flaw of browser technology?

How many times have you written the ultimate riposte on a forum only to watch it disappear into never-never-land?

The number one complaint about web based user interfaces is the ability to obliterate your work in the blink of an eye. While there are technical explanations for why this occurs, and manual techniques to help prevent loss, there has not been enough effort to resolve this recurring nightmare of an issue.

If we could come up with ways to prevent this from happening and drop it in the core of DotNetNuke, it would really change the world. Therein lies a challenge to everyone reading this – save the data from each control on a form to fix this data entry loss once and for all – creating the defacto standard for user friendly web applications.

[Subliminal seduction: AJAX]

That will be the hard part. The following examples are extremely easy to fix and should be a part of your everyday implementation of user interfaces.

10) Don’t repeat words 

Data grids, views and repeaters are very useful in any application, yet it is far too easy to replicate information. Try not to use the “Select, Edit, Delete” technique on detail lines. Ideally use a hyperlink to the data you want to edit, and/or a simple graphic to indicate operations such as delete. It is much more intuitive for the user.

9) Don’t conditionally hide things

Nothing is worse than trying to guess where a field or option is if it hidden and only displayed when something else is changed. At least display the hidden fields grayed out (disabled), then enable or disable them accordingly to your logic. This helps users remember where these features are.

Added bonus: Tool tips are not the best way to display important information

8) Don’t be negative

Use simple words or phrases for fieldname and never use “Not” within a fieldname or label. Checkboxes should be as intuitive as possible, checked means yes, not checked means no. Adding “Not” or “Disabled” to a field or description will confuse a user and probably give yourself grief when you are coding around the data.

For a great example of how not to describe things, in Microsoft Internet Explorer select Tools|Options and click on the Advanced tab. Read through the settings and you will quickly understand how it can be confusing.

7) Limit Drop Down Listbox Information

Listboxes are great for a limited amount of data, anything more than a page is a waste and will cause operator data entry errors. Populating a listbox from an entire customer or item list is a no-no, use a search textbox to list related results instead. Add a hyperlink to the results to help the user get there quickly.
Listboxes with multi-select should be replaced with a checkbox list.

Often you can use other techniques to get the job accomplished. For example, instead of making an order entry form with a drop down list box of customers let the user find a customer and use a New Order button on the customer information page.

6) Careful with colors

This is a personal issue because I suffer from colorblindness. I don’t know how many times I’ve seen a colored ball or square that represents something, but the legend and data it refers to is useless to me when I just can’t see the difference between colors. Please use different shapes or other techniques to convey this type of information.

508 Accessibility Guidelines, Subpart B, Section 1194.21, Subsection (i)

5) Click here

Users do not need to be told to “click here.” If the text does not clearly indicate a link, redesign the content so it does. Also, never use double clicks in a web application as they will totally confuse a user.

Consider the Three Click Rule. If a user can’t find what they are looking for within three clicks, they are likely to get frustrated and leave your site. (Although scientifically refuted, the concept is valuable and helpful to focus on the true needs of users.)

While we’re on the subject of clicking, never, ever, tell a user not to click something twice. Disable the button or take them to a new page so they can’t do it in the first place! This is by far the best example of indolence and creates all sorts of opportunity for users to break your application (or keep your customer service department busy). There is absolutely no excuse for any developer to tell a user not to press something on the screen.

4) Content Complexity

The name of the game is not to overwhelm your viewer with as much information that can possibly fit on a page. Use extra white space, single line paragraphs, and a consistent font to display data to the user. Use the skin to change appearance application wide, and rarely use italics, bold, or special colors.

Unless you are a graphics designer, or writing a game, your modules should be planned around the task at hand. You don’t need exciting graphics or flash animations to find customers, view daily sales, or print an invoice.

3) Data Entry – Errors

Data fields should be validated as mistakes are made, not in a group after the submit button is pressed, and definitely not in a popup or msgbox. Page by page validation is extremely confusing and rarely helps a user understand what to fix in the first place.

This is a difficult process today with server post-backs and page refreshing, but I think you will see some “refreshing” enhancements soon using Ajax.

2) Data Entry – Formatting Clues

The most ridiculous (and quite common) user interface issue is to tell the user how to format something. “Don’t enter dashes or spaces” for a credit card is a great example. Give me a break. If a programmer could not add these two lines of code, they should not be writing applications, never mind applications that deal with money!

1) Make Users Successful

Remember that the user interface will ultimately determine the effectiveness and popularity of your program. You may have implemented many features in your system, but when a user can’t complete their tasks easily and efficiently they will find other ways (and other applications) to get the job done.

Your user interface should be designed with one simple goal – to make your users successful. When they are successful at their job, everyone can share the rewards.

I hope you have enjoyed my ramblings thus far. I intend to continue with a few more topics to cover the basics, and then get into some real code from real projects.

Real World DotNetnuke Part II

This is the second article in Dwayne Baldwin’s series on Real World DotNetNuke:

Real World DotNetNuke – Part II

But we have always done it that way.

Yesterday has gone.

Today we have all sorts of ways to accomplish what we need. There are many stories about how things have always worked, but here are my two favorites from the U.S. Army.

The first involves a brand new warship with a fancy gunning system that could target anything in real time. The problem was that the fire button wouldn’t work for 15 seconds.

It turned out that this long practiced rule of thumb was implemented during the days of the horse and canon. The operator was supposed to wait 15 seconds after aiming the canon in order to let the horse settle down and not jerk the canon.

So they have this multi-million dollar, top of the line, technically superior gun that has a 15 second lockout feature because that was the way it had been done for nearly a hundred years!

The second story involves the Army procurement process. They needed a dependable supply of llama dung, as required by the specifications for treating leather used in airplane seats and jackets. Due to unreliable shipping methods at the time, the Army attempted to establish a herd a llamas in New Jersey. No one suspected anything until someone had trouble filling the request

It turned out that the US Army had copied the specifications from the British Army, dating back to Great Britain’s era of colonial expansion. New leather on saddles made the horses skittish and unmanageable. Treating the leather with llama dung created a different odor that calmed the horses. The treatment became part of the leather’s specification, which remained unchanged for a century

I’m sure you can look around your organization and find similar stories. Many people do not like change, and use the best excuses to keep things as they are. Because it has always been done that way does not mean that it cannot be done in a different way. The trick here is to look for rote procedures and discover ways to improve the process

In order to use the right tool for the job, sometimes you have to understand the job itself. Is this mass importing of data something that needs to be done at the end of the month? Why do we have an end of day process? Why does this batch process have to run at night? Should the console to operate these jobs be on a web server?

I prefer to know about the exceptions rather then the things that work. I do not want to be notified of every order processed today; I am only interested in the totals and the ones that experienced problems. Of course I can look up an audit trail to see what occurred, but I rarely need to watch successful processes

Should I develop some fancy progress bar that displays naked women (or men) on my browser while I wait for a job to run? I have to ask – why do I have to login and click on something to launch this job from a web browser in the first place

That is an example of the wrong tool for the job.

Another system I developed uses SQL Reporting Services to display an invoice on the screen. That got me thinking… how am I going to display this invoice in a DotNetNuke HTML module?

The right tool is Reporting Services.

So I wrote a module to render the invoice using Reporting Services and display it within the DotNetNuke application. I can choose to render a Windows metafile, a PDF or an Excel spreadsheet, simply by changing a single parameter in the call to Reporting Services. The payoff is that now a customer can login to the company portal, and view their invoice online. What they see in their browser is *exactly* what was printed on the invoice

Now I ask, is there any reason to print the invoice in the first place

Why not email the invoice as a file directly to the customer? Or email a link directly to the invoice and they can use the print module contents built into DotNetNuke. The customer can ultimately decide whether or not to print the invoice. Best idea yet?

Allow the customer to edit their online profile, and they can choose how they want to handle the process!

In any business process there are steps from start to finish. The best designed systems allow you to hook any process (i.e: pre-render, page_load, shipping, invoicing,) to add functionality. For example, if an application allowed you to add a call to your .net code after printing an invoice, you could call a web service to update a dissimilar system anywhere in the world.

I love the commercial where they guy pays for his coffee with his bank card and waits for the debit to appear on his PDA. That is the way people want to work – in real-time. Jobs should not be batched because that’s the way it has always been done.

Customer statements are another example of a wasteful process.

Not only is your organization wasting money printing and mailing the statements, they are always inaccurate and out of date by the time they are received. Put customer statements on line, and allow the customer to view it at any time.

Depending on your company, if you had a customer on watch, you can be notified that they just looked at their statement. So why not phone them while your statement is on their screen. (Slightly nasty, but very effective.)

Look around your organization to see how you can make more things happen in real time.

Real World DotNetnuke Part 1

A while back there were a series of posts on the ASP.Net forums made by Dwayne J. Baldwin on his opinion of Real World DotNetNuke. I thought the posts where very inciteful and basically a decent read. Its very apparent that Dwayne has many years in the software development industry and in my opinion covered this subject very well. I was impressed with Dwayne’s incites so I asked if he would mind if I re-posted his subject matter. Being the nice guy he is, he agreed to let me re-post it, I just never got around to doing it.

This is the first of three posts Dwayne made on this subject and the next two will follow

Part 1 a sequence of ramblings to help others understand DotNetNuke

There are no magical answers when it comes to software development. Design = choices. Requirements determine development. Processes change. Space is cheap.RAM is cheap. Users make mistakes. Feature creep. Etc., etc

I have three fundamental rules for any development project…
1) Don’t reinvent the wheel.
2) Use the proper tool for the job. (Give a kid a hammer and the world becomes a nail.)
3) He who laughs last – made a backup.

The job of a programmer is really one of an interpreter; he or she must examine the business processes or methods then translate them into something that the computer understands. After the computer performs the necessary tasks it must be presented back to the people who use the system.

If a small business owner randomly draws money from the cash drawer, a fancy computer system is not going to help them manage an accurate accounting system. If a warehouse operation does not tally the fastest moving items and rearrange item locations on a regular basis, a computer or computer program is not going to improve productivity.

Q)What do you get when you automate a bad system?
A) An automated bad system.

All of the software that we create should be modeled around real world examples. Class libraries should represent way things really work. They should allow for “communication failure” just as when someone is not available for some reason. They should be able to retry an operation. They should be organized around security – not patched with security constraints in spaghetti code. They should allow for exceptions and inform the proper staff members (or authorities) to the situation.

Where am I going with all of this mumbo jumbo? I am actually setting you up for a successful implementation of DotNetNuke in a real world application.

If you examine the most popular small business accounting packages, they are relatively similar. Accpac, QuickBooks, and Microsoft Small Business Accounting all have a similar look and feel. Microsoft evens claims that SBA looks like Office (due to the familiar controls). Now step back and consider how the user interface is used to perform actual tasks.

All the functionality of the package is available from a menu, a hyper link, or a keyboard shortcut. Common tasks may be grouped together, or even organized into lists, but every task is available by navigating the screens of the application. QuickBooks and SBA have a shortcut menu on the left, and a browser literally fills the rest of the screen. The browser portion is divided into sections just like DotNetNuke modules appear on a page. One module may display a summary of all bank accounts, another module displays a single bank account register.

A few years ago, if a company asked you to create a system using a standard user interface, login mechanism, integrated security, master templates, departmental features, and have the system available world wide, you would need an army of developers and years to put it together.

Using DotNetNuke with membership, security, and skinning, you can build a web based front end comparable to any application that you have seen or can imagine. You can prototype the user interface today and demonstrate it to your client tomorrow!

As you add new functionality to your DotNetNuke application, you can post a time limited announcement directly within your program; using nothing more than a browser; on a laptop,on a lounge chair,on a beach…