Davai Blog

Suppose you want to know how many times the string str occurs in a text blob. No predefined function exusts in SQL for such a task, and doing it with loops is costly, especially if you want to rank records according to the number of occurrences for each, which would be next to impossible.

First let’s look at the context. Suppose you want to keep track of registered users who viewed certain records. Creating a new row in the database each time someone views a record would balloon the table in no time, especially for a large number of users and records.

A common practice today is to keep a running sums table structure with a string blob column to which you keep appending context related data and increase the sum. In this case, you would have a “views” column for each record to store the number of times the record has been viewed in total (not needed in this case), as well as the text blob which would store user names of those who viewed the record, all as one big string, appending the user name each time the user views the record.

This is practical since the number of rows in the table stays the same as each record has one and only one row. However, it gets tricky if you want to know how many times a particular user viewed the record. The user’s ID has been appended numerous times to the blob field, but the blob is one big string, so how would you know how many times that particular ID appears in the blob?

As I said before, no SQL function exists to deal with this problem, but there is a workaround. In simple terms, you retrieve the blob, measure its length, replace all occurences of the needed ID with an empty string, measure the length of the new blob, subtract it from the original length, and finally divide the difference by the number of digits in the ID.

SQL: ( LENGTH(blob) - LENGTH( REPLACE(blob, ‘ID’, ”) ) ) / LENGTH(ID)

If you want to sort the table according to the number of views, you add a couple of elements to get

… ( LENGTH(blob) - LENGTH( REPLACE(blob, ‘ID’, ”) ) ) / LENGTH(ID) AS param … ORDER BY param [DESC]

and if you want to output the numbers, you’ll need to wrap this in a ROUND() function to eliminate the decimal zeros.

ROUND( ( LENGTH(blob) - LENGTH( REPLACE(blob, ‘ID’, ”) ) ) / LENGTH(ID) )

The disadvantage of retrieving all the blobs from the database is still worth it, especially in the long run, since otherwise your table will keep on growing. One way to speed up the query is to extract blobs that have at least one instance of the desired ID. To do that, you ad a LIKE ‘%ID%’ in the WHERE clause, which will eliminate the irrelevant records.

There is a reason management often distrusts the IT staff and their budget demands. We complain about how managers don’t understand what’s going on and are unappreciative of the work developers put into any given project, but that’s all thanks to a few who ruin it for all of us. Here is a perfect example:

We are currently working on the development of a massive information system for a research institution, part of which will be extracting and manipulating data from other systems already built and currently managed by various government agencies.

During the design stage, I received the documentation for the systems in place so we could put together a data transfer mechanism. In simple terms, the documentation stated that one record can have one instance in one year. Period. Example: Bob paid $10 in 2008.

We built the module to extract the data, which took considerable time and resources, tested it on some sample records provided, and were hoping to move on to other things after the first data collection. However, the collector crashed 7 hours into the run. It turns out there are exceptions to the rule. Bob might have paid the $10, but he then could have paid another $12, both in 2008. The problem was that the developers decided not to handle it, so the system wouldn’t allow it’s users to enter two records for the same year.

It is in our human nature to scramble for a creative solution to any given problem, and the more creative (read: MacGyver) it is, the better we feel about ourselves when we succeed. In this case, the users decided to rename the entity for the second record, calling Bob “Bobby” for the $12 transaction and technically creating a new entity. I can figure out that Bob is Bobby, but our data collector can’t. In our case the architecture was flawed and it was my job to explain to the client that we just burned a lot of money on something that is now a virtual paper weight.

The whole fiasco wasn’t our fault, as we went by the documentation and data samples provided, but blaming it on the previous guy doesn’t fly in the corporate world. I of course took the heat and went back to the drawing board, thanking my lucky stars that we weren’t sacked, but I’m pretty confident that our client will think three times before investing any more money into future IT projects, all thanks to a few imbeciles who didn’t bother or had a deadline they had to make at any cost, which in this case turned out to be steep.

The business world runs on information systems, and yet we just can’t get it right when it comes to building them. We learn about modularity and coupling at an early age, but to most of us the notion appears to apply only to coding, so when a database comes into the mix, we don’t think twice about the fact that all of our modules will be dependent on one central storage structure.

Here’s a hypothetical example. Say a startup supplier company XYZ built an information system to handle customer information, inventory, financial reporting, and payroll. All of these components are modules of the system, but due to the lazy nature of developers (why do you think we strive to get computers to do everything for us?) the data storage is handled by one central database. A while later additional modules are built to satisfy new business requirements as the company expands, and these modules further grow the database structure.

Now suppose a small change is introduced into the schema. Let’s say that the phone number field got expanded because the firm now deals with customers overseas. This tiny change will cost the company gigantic money. Why? Because the source code (both business and presentation logic) in all modules is now in need of attention, the data storage and retrieval procedures require changes, all of the existing automated tests are now bogus, and the documentation needs an update. You must now go through everything you have in order to find all instances where the structural change affects the system. All of this due to one small modification. If the initial schema was badly made, expect the maintenance cost of the perfectly modulated system to skyrocket.

It is surprising to me that most systems built today still go with the central data management module. I guess we never learn, but if we did, how would one avoid database coupling? There are a few ways to deal with it.

You can’t effectively “modulate” a database schema by simply creating multiple databases for the system modules. The complexity of such a system would be enormous since any particular module will need to work with several databases at once, unless you duplicate the information, in which case you must ensure coherence among the copies. All in all, it would be a gigantic mess.

One solution would be to put together multiple databases without data duplication, and cap it with a central data retrieval system. All storage and retrieval commands would have to go through this module, after which they will be spread through the databases. A module can be built to work with the database it needs, so changes to other database structures won’t affect it. Any changes will require tweaking the storage and retrieval module as well as the source code of the module affected. It isn’t a perfect solution, but it isn’t the apocalypse version.

Another way would be to use a central database and a number of local data storages. A module can have a minimal duplicate data set stored locally for frequent operations and the main database would include a trigger to update the local data set if it is updated in central storage, and vice versa. This is a good solution if the various system components mostly use unique parts of the database for standard operation.

My final proposition, the wildcard, is to use an entity-attribute-value database schema. If done right, this type of implementation is very forgiving when it comes to change. Since there is no “final” schema at any point of its existence, the modules are built in accordance with this constraint, so changes are absorbed much more easily. The cost of developing a system with an EAV model is usually higher, at least it was for the two projects I directed, but if you anticipate constant evolution of your model, the future savings are worth it.

If you are already stuck in a coupling mess, the best you can do is make sure additional modules are built using one of the techniques mentioned above, and don’t forget to learn from your mistakes.

As any software developer can attest, one of the first things we learn during our baby steps as software engineers in the making is to gather requirements before anything else. I really tried to stick to that philosophy over the years, mainly because it’s logical. If I am building a system for a client, I should ask for what they want, right? Yes, and I do, but then why do I get a “meh” response once the system is actually built? Why do people often have a change of heart once they actually see what they requested? I wish I knew, but lately I have been trying to change my approach to requirement gathering and the development process in general.

I have a simple theory on this phenomenon: often times people don’t know what they want. They have a general idea of what they want to accomplish, but if you ask for specifics, you are likely to get in trouble. We were all taught to ask the right questions and only proceed based on client feedback. That may work for simple projects, but anything more complex than a calculator requires a different approach. I think Waldo was one of the first software engineers, but then he saw what he got himself into, and now he is hiding.

In the mid-90s iterative development came to the rescue, but unless you participated in a real project using iterations (not the stuff they try out in schools) you don’t really see the light in all of its brightness. Iterative models usually cost more money, unlike what you have been told, but with them you produce better software, and better software is worth more money, so in the end everyone is happy!

Take a moment and follow the logic, then everyone look at each other and go “huh?”.

If you look up the Wikipedia entry for “Agile Software Development“, you are greeted with warnings about how the article is poorly written, needs an expert, and has no references (Update: some of the warnings have been removed, and I assume dealt with). They have perfectly written article on “The Year 10,000 problem“, with which we’ll have to deal with in uhh… so ten thousand minus… what are we today… two thousand eight… so umm… carry the one… uh getting a decimal here, weird… umm… a freakin’ long time! If you look at the PageRank of the two pages (7 and 5 respectively), you know that people are adapting iterations, and yet the article gives a first impression of being written by some jobless douche bag with a Cheeto-stained shirt.

The reason for my ranting is that in today’s world the investment in software development is often considered money not-so-well spent. The belief was a result of projects flaming out all over the place, but people didn’t stop to think that maybe, just maybe, poor management and lack of client participation might have been the primary cause.

Way too often I receive requests to build a system or a web application and given the requirements, after which I am completely forgotten until demo day. Requests for information or approval are often ignored or take too long, the project time-line balloons, and because this makes the developers look bad, we switch to traditional models and adapt the lets-just-get-it-over-with attitude. The end result is a mediocre product, if you’re lucky.

Just to throw out a number, I would say roughly 50% of all large information systems I ever used were crap. A lot of them weren’t even used by the people who dumped piles of dough to develop them in the first place. I can’t count the number of times I witnessed a company pay up to build a system, but revert to using Excel a short while later. The blame usually fell on the developers and the world kept on turning.

Regardless of how fast technology improves, if developers and customers (users) alike don’t work together, everyone loses (jobs, capital, productivity) and skepticism breeds. At least it’s good to know that when year 9999 rolls around, there will be a serious need for programmers, so we should all keep our CVs up to date.

I recently experienced my first software development “holy &#$@%!” moment as a project manager. A few months ago I was contracted to develop a database system that collects all sorts of financial data and produces various reports to help company staff quickly use and manipulate information needed in their day to day operations. The staff manager was a close friend, and he pushed the initiative for the system forward through upper management, after which I got involved based on his recommendation. My goal was to keep the costs low so that the manager gets the “attaboy” from his bosses for helping increase staff efficiency on the cheap, and since the system wasn’t mission critical, I thought that I could save a good stack of Benjamins on testing. Whatever bug slipped through the cracks can be fixed when found while the system is in use - no problem, I thought, and it would have been true.

My master plan had legs, and the development cost was close to what I predicted. Two weeks before the expected launch, we demoed the system to upper management, and the demo went great. The system was firing on all cylinders and everyone was in awe of what was going on. Great, right? Yes, well, too great actually. A few days after the demo I received notice that the company was planning to get a joint patent on the system and release version 1.0, an entirely unknown universe to me. Right then and there I felt the inevitable sensation of my initial testing decisions streaking back to bite me on the ass.

Releasing version 1.0 is probably the scariest part of software development. Your head fills up with questions to which there are no answers. Will the software fly with the customers? Is the product buggy? Is the rainbow themed flower a good choice for an icon on the “Save Report” button? I don’t have the statistics on this, but I’m willing to bet that the baldest software engineers have the most 1.0 release experience.

Since I never released a commercial 1.0 of my own before, I thought I’d come up with a short “how-to 1.0″ guide to try and convince my hair to stay put. Here’s what I have so far:

Get your customers involved in testing
People who are going to be using the software will work with it in a certain way, and it might be different from what the developers foresaw, which will lead to the discovery of unexpected bugs.

Define “done”
1.0 can push developers to constantly tweak the software to no end. Avoid it by setting a list of goals the software must accomplish. As soon as it does, test and release. There is a reason they invented 1.1, so don’t fret.

Put together automated tests
Bugs will be found, no ifs. You want to be sure a fixed bug doesn’t spawn others.

Put together a bug travel system
When a bug is found, what happens? There is no “OFF!” to help us deal with it, so come up with a plan. Log it, get Pablo to fix it, rerun automated tests. There’s a simple one right there. Build on it by taking into account what your particular situation needs.

Set a timeline and stick to it
Nobody is ever ready, but you should trust your software. Make sure it is stable, and let it go.

Promote expression
People testing the software, especially customers, will often have propositions on new or modified features. Take note of them for version 1.1, but fight the temptation to put it in this instant, unless you had a “duh” moment and forgot a crucial functionality feature.

Listen to customer feedback closely and developer feedback sparingly
The people who will be using the software are the customers, so what they say is important. The developers might have hundreds of awesome modifications they want done, but are they also important for the customer? Be sure to know.

This is what I have so far in dealing with 1.0 releases, but I’m pretty sure this list will grow and evolve as I get through a few initial launches, hopefully with most of my hair still riding shotgun.

My first important role in a major software development project was when I was hired By Pratt & Whitney Canada to work on a customer service system of a plane engine repair company PWC recently acquired. I had three potential propositions in the works. All three involved the development of an online customer payment system. The first one included a company in the States, and the two others involved companies offshore. The total costs of the three propositions were $48000, $15000, and $8000 respectively. It was then that I discovered the great benefits of outsourcing.

I think most people in the business know that it costs less to get coding done in places like India, China, Eastern Europe, and soon enough Africa, than in North America. However, few take advantage of that because of skepticism or fear of the unknown. How can you possibly let someone an ocean or two away develop your application? A good chunk of developers are afraid of this kind of delegation, and there is some merit to that, but I think by following some guidelines anyone can take full advantage of $5-10/hour hyper-efficient programmers located a number of timezones away. I have, and so can you! You won’t believe the drop in development costs.

First, keep it simple. Don’t ever try to dump the whole project onto some firm overseas and expect it to be done well. Split the work into a number of simple modules and write out the functionality. List what comes in and out in detail, and outsource each module separately. The design and some testing should be done in-house, and the development can be outsourced.

Next, look up offshore development companies and get a list of eight to ten you think can do the job. Check out their portfolios and contact a few of their clients to see how they liked the service. It might take a little bit of time, but you are looking for a company with which to do business for years to come, so take the time needed. Pick out three or four companies that you are comfortable with, and you have your future offshore development office almost set up. Be sure that companies you pick have offices with addresses, telephone numbers, and some sort of customer service. You can risk picking a raggedy-looking firm, and it might reduce your cost further, but you are asking for headaches.

Now it is time to start a bidding war. Let me tell you a secret. Any initial quote you get has a 70% profit attached to it, or perhaps more. The reason for that is when you get a quote from a N.A. company and a real quote from offshore, you might think something fishy is going on with the latter. Therefore offshore quotes are often juiced up to look more legitimate. A couple of years back I was developing a client information tracking database system for an employment agency, and one of the modules was an option to send a fax through a machine connected to the company LAN. I decided to outsource it, and my initial quotes came back at $4800, $2500, and $1800. I openly let all three firms know that company #3 offered $1800 and is currently in the lead. It wasn’t a day before I started getting offers below $1500, and after two days I settled for $800. To really get the best possible quote, be sure to mention that you are testing the outsourcing waters and looking for offshore partners for future projects, with the current project being a tryout.

One important element of note is the pricing structure. Be sure to have the quote for the work and not the hourly rate. In case you aren’t satisfied with the initial delivery, you can always request changes without fear of ballooning the cost.

Keep working on your short list of firms you outsource to, and be sure to always let them know you have options. There might be some discomforts such as the language barrier (English VS funny English + long distance telephony) and different office hours, but it’s worth the savings.

There are some fields that are hard to outsource, such as game development and graphic design (ex: corporate identity), but otherwise you can develop offshore and save your money, and I’m not just pulling that out of my ass like the ING guy.

About 6 years ago, when I started thinking of software development as a career, I had a conversation with a friend, a C programmer working for a local firm, about the future of software. My opinion was that desktop applications (what we know them as today) will be run on remote servers in the future. My argument was that with the advancement of technology, we wouldn’t need to install software and run it locally. He thought I was silly.

Today, with the growing popularity of Google Docs (and there are lesser known others), my silly projections are starting to look more and more like reality. I think it’s important for anyone thinking of going into software development to at least be aware of this. Software and web development are slowly merging into one. Going back to Google Docs, you can edit text, spreadsheet, and presentation files purely online with no necessary installation, and then save the files locally once done. No, this isn’t a Google Docs promotional ad (I actually used it a couple of times, and it didn’t take my breath away), but this is just the tip of the iceberg when it comes to user applications.

Let me present a hypothetical example of a popular application being run remotely. Suppose Photoshop, a graphics editing application, ran on servers administered by Adobe. To use it, I would purchase a license (just as I do now when I buy the CD), and use the software through a browser (or client application). I would perform some tasks, each one firing off a request to the server, and see the results on my screen. While the computing power required from the servers would be massive, technology can only improve, so it’s a matter of time. In addition, the current cost of distribution could instead be invested in needed hardware. Is this example far fetched? I don’t think so. The cost of hardware keeps dropping, while the cost of distribution can only rise. Eventually, due to the need to stay competitive and technological progress, companies will consider going remote.

This concept can even include operating systems. There are a number of big companies that use diskless computers that load the OS from the main server through the network, so why can’t the network be the Internet? I can even see a world where I can load up Windows one day, and Linux the next. There are sure to be quirks to work out, but that no longer requires a miracle, but an investment.

There are massive advantages for such a concept to become reality. First, it would mean the end of software piracy, which I’m guessing is important to development companies. Second, we wouldn’t have as much of a performance barrier due to open competition among developers. I’m confident Microsoft would think twice before asking me to buy a new machine in order to use their software since I could easily switch to their competition. Also, the virus and spyware issues wouldn’t be the problem of the user, and I trust that companies running the servers would do a better job in dealing with it than individuals as it is the case today.

We would have to deal with numerous issues such as the users being dependent on remote servers, but the advantages far outweigh any inconveniences, and tech support would be much easier to deal with as companies would have to resolve issues with their servers, and not with individual user machines.

This is my view of the future, and while it might be far fetched, it is definitely an idea to be explored further.

I have forever been a user of PC. Like many, I just can’t switch to a Mac and its cyclops mouse, but I have to admit, it is becoming more and more tempting. Why? Vista.

I was forced to leave XP behind as I needed a new computer to satisfy the growing needs of a software developer due to the heavy development environments we now use. I loved XP because it was like an American car. It broke down on occasion, but it was inexpensive to fix, and you can do it yourself.

Along came Vista, which made my new HP laptop into a clock with web surfing ability. I could have just gotten an iPhone and enjoyed it on the go, but I let my love affair with PC cloud my judgment, and I am waiting for Linux to have number of features I need before considering a switch.

Update: I just stumbled across this, which definitely says something about the worldwide Vista love.

So where did Vista go wrong? We constantly get clues from the Mac VS PC commercials they keep running on TV, but the problem lies much deeper. Microsoft screwed up because of their greed and arrogance. They chose to focus on the fancy stuff instead of making sure the OS actually worked. My laptop recovers “from a serious error” every time I wake it from its sleep, but I have floating transparent windows with Aero. How nice. I used to wonder how can such large corporations with unlimited brain power make mistakes that are obvious to children who still believe in Santa. The answer? Shortsightedness. Yes, I was very impressed with some of the user interface features they added, and I still love the search feature, which in XP was useless, but a month into my Vista experience, I got used to the things I was impressed with, which is natural, but was still highly annoyed with all the deficiencies. I’m thinking the developers didn’t foresee past the first month of usage.

How does this happen? How can something this obvious get by levels of management and supervision all the way to BestBuy? Frustration. Vista was scheduled for release way before it all actually went down due to numerous scrapping and redoing of the work, and in the end pressure mounted to release the damn thing, so they did. It didn’t take me a month to find critical flaws in the system, and I am one man on one computer. Mr. Gates has a team of testers getting six figure salaries, and I am supposed to believe they missed all of this? They didn’t realize that the security features get annoying after a week and the users might tend to simply turn them off? Wasn’t the whole purpose of releasing Vista to fix critical security flaws and improve the Windows experience? This could have been done with a Service Pack, but Microsoft decided to go all the way instead. And the whole requirement to buy a new computer if you wish to run Vista really got under a lot of people’s skin. However, Microsoft had no choice, Vista eats up over 500 MB of RAM just past start-up, while most systems running XP had 512, and that was with the integrated graphics card. Forcing people to spend big money on new computers is a big no-no.

So who’s fault is all of this exactly? Simple. Steve Jobs. The guy oversaw Mac go from weird to cool, and Mr. Gates got jealous, so he decided to “out-cool” Mac, which made MS developers lose sight of the most important aspect of an operating system: it has to work. If it doesn’t work, no amount of cool features can mask that. They were so busy fancying up Vista that they ignored the basics, and now the people are lashing out and Mac is taking advantage.

We all know Microsoft doesn’t employ idiots. Their hiring process is legendary. It’s like a game where you advance from one level to the next without getting axed along the way. Very few reach their goal, but those that do are greatly rewarded. So then how can all those people with all that thinking power let something like Vista escape into the world? Simple. Work culture. I know many people who got hired to work for Microsoft, and many more who didn’t, and I noticed a pattern. Microsoft prefers pure coders over all-around candidates. Pure coders are geniuses that can sort an array in hundreds of different ways, but when it comes time to tell the manager that what everyone is working on is flawed and will eventually blow up, they are nowhere to be found. I’m not saying that is the case for everyone hired, but the work culture absorbs the exceptions eventually.

Microsoft banked on the fact that PC users will be forced to live with and adapt to Vista regardless of its flaws, which is mostly true because they own the market, but this is a great shift in business strategy for a company that used to be known as operating with the mindset of a start-up concerned with being annihilated by the competition. Maybe Microsoft learned their lesson, since they scheduled the release of Windows 7 for 2009, less than three years after the release of Vista. By comparison, XP was out for six years before Vista came along. Although they will obviously not admit it, it’s a sign that even they know they screwed up. A lot of people still use XP, and they are already scheduling a new version of Windows. If it all works out, the lucky ones will go from XP to 7, but I’m not one of them. I’m just hoping Microsoft changed their approach for Windows 7, otherwise I’ll be among many taking a bite out of the apple. Not a good sign though that they are giving us Seinfeld and Porn Mode. How about that?

Speaking of Apple, they took great advantage of Microsoft’s mishap to lure away customers, but their business sense is a little lacking. The reason most people hesitate about switching to Mac is the fear of adapting to a new system. That is certainly my case. It’s not that I think I won’t be able to, it’s just that I naturally don’t want to. What Mac should have done is make their system resemble Windows just a tiny bit to give that feeling of familiarity to people looking to escape Vista (maybe a skin?). When Lindows came out (now known as Linspire), I was really tempted to switch because of the seemingly quick transition period. If Linspire had all the programs I needed then, I would have never had to use Vista. Mac does have the software most people need, but they need to give potential customers a sens of trust in that going from Vista to Leopard will be a smooth transition. I’m not talking about the hardcore crowd, but the average user.

Well, my little rant is over, and my firewall just stopped working, with Vista wondering why and pretending to look for a solution. I’ll help it out by restarting the system.

I often times get questions about user interface design, so I might as well lay out what I know. This is in no way a UI guide, and a lot of it is based on opinion and personal experience, but I put together quite a few control panels, and lately the feedback on them has been positive. I will admit to many UI mishaps in the past, but spotting and analyzing them is the only way to learn. Like most things in life, the more you do, the better you are at it.

Ok, so first off, to me a user interface can be for a particular software or web application, as well as for a simple brochure website (some people see it differently, but hey, this is my blog). In all cases, you want the user to do whatever you planned out flawlessly. That’s a biggie to achieve (how many times have you used a software and wanted to instead go hunting with Dick Cheney?) so I’ll break down the process I follow every time I build a UI.

Step 1: Know your audience

I often see people jump to the design stage without a thought about who will be using the UI. I’ll be frank. These people are idiots. The UI is like a shoe: it has to fit. The trick is to profile your future common users and set a lowest common denominator. This means that if half of your users can reprogram Vista to work, while the other half types only with their index fingers, you must design a UI for the latter user group, otherwise half of your audience will be wishing they went hunting with Dick instead of working with your application.

Now, it may seem you will upset the Uber users by forcing them to do the baby steps when working with the UI, but that can be solved with some ingenuity. For example, the browser you are currently using allows you to select and copy this text in multiple ways. You can either select->right click->Copy, select->Edit->Copy, or select->Ctrl+C, all of which do the same thing, but are created for different types of users. The index typing folks often use the Edit menu (from my experience) and have never heard of keyboard shortcuts, but the tech experts are not as mouse dependent.

Step 2: Put together a prototype

This step involves a number of important topics, so I’ll split it into subsections. Note that parts of this step must often times be repeated over and over until you get it right. Until you develop your knack, this is the pain you must endure.

- Start with your lowest common denominator
At first, create a sample UI to be used by the least tech-savvy group of users, and then add the functionality for the more sophisticated ones. If you do it the other way around, you will never be able to seamlessly water down from complex to simple.

A task can be performed in many ways, so make the choice wisely. Do you use big bright buttons with text and icons for the navigation menu, or do you simply have drop down boxes? It all depends on your lowest common denominator group.

- Use common conventions
We are all used to the drop-down menu on the top left, the status bar at the bottom, the page menu organized on top or on the side, certain icon images associated with certain actions (the [X] button always closes the window, regardless of the software you are using), etc. Use it to your advantage. You can try to get fancy and creative, which is sometimes necessary, but the more you can stick to known conventions, the less time users will spend learning to use the UI.

- Easy to learn, not easy to use
The heading says it all. Don’t try to get the user to “get it” at first glance, unless you know they won’t be coming back. The problem with the UI being easy to use right away is that you won’t pack the necessary functionality into it, and if you try to do so, the UI will become increasingly complex. Think of it as driving. The first time you drive a car is for the purpose of learning. It seems difficult and you suck at it. Years later you get into a car without thinking twice about what you have to do to get all that metal rolling, and driving is a breeze. The same concept can be applied to your UI, but with a shorter learning curve. You want your users to think the first time, but quickly become comfortable with all the functionality as they keep playing around with it.

- Usability wins over “cool” every time
I have noticed that many UI designers try really hard to impress the user with some fancy additions to the UI, which often makes them forget the real purpose of their work. The UI has to allow the user to perform certain tasks, and that’s it. If I’m working with a program that generates reports, and a chicken on the screen lays an egg every time I press a button (exaggerating, I know), someone somewhere lost direction. The developer might have thought that the user will be amused by the gimmick, and that might be true for the first 25 reports generated, but for number 26 and beyond, that chicken’s approval rating starts to drop considerably. This is more important than you can imagine, since the best form of advertising is word of mouth, and your work won’t profit much from it. As a reinforcing example, Google has forever been a text field and a button, and everybody loves it.

- Limit user input
This aspect of the design process is a little tricky and takes a few UI disasters to really master. The simple definition of it is not to force the user to click twice if something can be done with one click (unless it is of crucial importance, like deletion confirmations). The tricky part is to stray from common thinking. Suppose you are designing a website, and you require the user to perform two mouse clicks for some functionality to work because you fear that if you reduce it to one click, someone can accidentally fire off the feature and get redirected someplace they didn’t mean to go. That is true, but consider that if 1000 different users navigate the site, and two of them make this mistake, but the other 998 are quite happy with the quick process, you are much better off than with two users who are glad to have to click a second time, and 998 people wondering why are they being annoyed. A developer’s errors in judgment like these are what often causes the users to want to go hunting with Dick without them even understanding it. A user might be annoyed by the UI without really being able to pinpoint the exact cause (say, useless clicks). Also, often times the users that do make the mistake realize it, go back, and not reproduce that mistake in the future. This concept can be applied to any other aspect of UI design, such as if you are collecting information about your website visitors, don’t ask them for their name and phone number if you don’t need it. Just because many others do it doesn’t mean you have to. As a user, I want to be in and out when getting something done. Keep that in mind.

- Test, test, test
This is probably the most important part of the learning process, and yet most developers, especially during small-scale projects, completely ignore it. Rule of thumb: never assume anything. If you are sure that your navigation menu will be a blast to use and move on, you are likely shooting yourself in the foot. Try the following: find a few people in your inner circle that match the profile of your future users, present them with your prototype, list a few tasks you want them to accomplish, and observe what they do. Do not explain anything about your UI, not even a word. Note any struggles or delays in finding what they need. See if these are repeated as they move along the list of tasks. If they aren’t and the user is moving along much smoother, that means you are on the right track as your UI is easy to learn. If that isn’t the case (which is often the case), you screwed up and need to rethink your strategy, which is good, since screwing up and witnessing it first hand (preferably before launch) is the best learning process there is.

Step 3: Design it

Well, now that the prototype taught you a few things, you can finally put the UI together. It’s important to stick to the original plan, even as you find various things you believe you can add. If it is crucial, then redo the prototype step, but otherwise get the UI done. I live by the popular saying that better is the enemy of done, especially in any kind of design work, where no outcome is perfect and doesn’t have room for improvement. If your UI does what it is supposed to without annoying the user, you did your job, so be happy with it (unless of course the project is a hobby, in which case go nuts).

Also, you must finalize the minor details of the look and feel, such as colors and fonts. This doesn’t require much prototyping as there are guidelines you could follow, such as a bright yellow screen will most likely be difficult to work with.

Well, there you have it. Of course the user interface design process is much more detailed and complex, which is why tons of books exist on the subject, but if you follow these basic guidelines you will be alright as you learn the trade. Also, my word count says I’m past 1600, which is longer than anything I ever wrote without filling it up with quotes (for school purposes), so I’m in unfamiliar territory! Good luck and let me know what you think.