Her is an excerpt from my former blog regarding user interface aspects... It's interesting to see how my opinion evolved from this kind of thinking to CROAM
previous web logs can be found @ blogspot
---><8----------------------
A user-interface is one of the points that makes or breaks your program when users start to work with it. Millions of euros are being invested into programs that never get used, since the users find it un-intuitive.
Most ICT people tend to think in abstract concepts like objects and relations due to their education, while most users think in terms of a process. In each business you can identify several business processes.
Let's take an order for example:
- The company receives a customer's order for several items.
- The company arranges a delivery for the order.
- At the end of the month the an Invoice from the former Delivery is being sent to the Customer.
- The company receives a payment notice for the order.
Of course this is not a complete process, the customer could cancel the order, or the delivery could fail, he could refuse to pay, or only pay a part of the invoice, ...
Most programs offer a view on the words in BOLD, called objects . While you can input all different steps noted above in such a view, it's hard to keep an overview of what you were doing, especially if it's been a few weeks since you last touched it. You have to examine his orders/invoices If you remember you still need to do something...
In order to solve this problem we need to look at it from a different point of view. People think in processes and their phase it's in.
In this case we have the following situation:
- 3 initiators : Customer / Company / End of the month
- 4 steps : order / delivery / invoicing / payment
- all of these steps could have different states : Pending / Busy / Finished / Canceled
(note this is a simple example, and we could have several other initiators, steps and states for invoices)
In an ideal situation, the Company would not be working with customers,orders,invoices, items, deliveries and payments directly, but with processes and their state. That would imply having a wizard for each process, that guides you towards the next step in this process, depending on the initiator and the previous phase/state . That's where the user-interface comes in. What people really need is a wizard-like form to guide them to the next step.... Please note that most of the time it is not profitable from a return-on-investment point of view for a program to have all the processes directly accessible from a wizard. People should still be able to browse data using the object-interface, but more info regarding this subject will be in my next blog entry. This article was actually written as a post-reflection to our first version of CUDI (the core universal database). We will now solve the issues noted in this document, and apply them to our second version.
Subscribe