Personalization in web applications (part 2)
In this 2nd post which is dedicated to Personalization, I shall continue to list some features that I think are interesting and welcome by all users. I am sure that you will find “yourselves” in there (if you are web developers) or that you will see a wish-list (if you are internet users).
Remember, the object of Personalization is to make the web system more attractive and more usable at the same time. After all, with all these systems and sites out there, you have to make a difference if you want the users to stick to your system, instead of the next guy’s.
Save Searches
All web systems provide some kind of search facility, be it a generic search engine that looks inside the web site and returns relevant documents or be it a search facility for the supported entities of that web system, such as “invoice search”, “loan search”, “customer search” etc.
I would bet that a user friendly search offers a whole bunch of search criteria. I would also bet that having an exhaustive list of search criteria can be overkilling for those of you that are used to work with these search engines in one (or two) specific way. For example, an accounting employee usually needs a “search customer by name” function. Nothing else. Who cares if the search engine also provides the city of residence as an additional criterion!
The mistake that a lot of developers do is that they overwhelm the user with a bunch of features and thus they achieve a level of complexity that is not welcome by some… On the other hand – yes, you are right – you just can’t have a “dummy” search with just a couple of obvious fields.
What do you do? You give the ability to the end user to save their searches. That way, low-end users will be able to just click on their saved search and the system will automatically pop-up their favorite or most common search criteria list.
Let alone the fact that you could have a fast path to “all my saved searches”. So you can present to the user all of their most-commonly used searches, in just a click. Simple, yet invaluable!
My personal settings
The more parametrical a system is, the more clicks and selections it will require by the user. This is perfectly understandable by you and me, but – make no mistake – the end user simply does not understand why they have to execute 15 clicks to issue a cash receipt of 15 dollars!
The name of the game is “defaults”. You should equip you system with default values for some very critical functions. Default values that can be changed by the end-user with just a click. A classical example is that of an accounting employee who – in the morning – is posting tens of accounting entries from bank statements and when they’re done with it, they start to register supplier invoices. The “bank statement” document and the “supplier invoice” document should appear automatically to them, by their selection. Imagine that for X number of documents they save exactly X clicks! A huge benefit. And your system is probably executing X less screen refreshes of the web browser. That’s… more benefit!
Customization of literals
I’m sure that you’ve seen this before. One of your customers does not like the term “status: invoiced” and they would prefer “status: closed”. The next customer argues that “closed” means something bad and they would prefer “status: completed”. And, on top, they say “why is it so hard to change just a small word? Will it take you more than 3 seconds to do it?”. There you have it: a “simple” request which you can’t serve and thus you are becoming the cumbersome and “stick-to-your-own-ways” IT guy.
But seriously, you should consider creating a glossary of terms widely used in your system. Then, a user (or better a group of users, say those working in the same organization or company) can agree that “invoiced” can be changed to “completed”.
This is the kind of argument that a user would not raise back in the days of monstrous ERP’s of the 80’s, but in today’s world of www and SaaS, they do have increased requirements, even on the wording issue.
Customization of frequent and critical transactions
Have you ever seen two users that imagine the customer file structure the same way? No? Me neither! Everybody wants the screen to show different data, to hide and show fields as they wish, even to alter validation rules from one user to another.
I recently had a customer that said “the correct layout of the fields is not last-name-first but first-name-first”. Yep, I was forced to customize the customer form to show fields “the other way around” (and I did it parametrically because I didn’t want my other SaaS users to see any difference on their layout).
Therefore you need to be able to customize your screens as per the user’s requirements. Again, an accounting user cannot see why they have to enter the customer’s email, while the marketing user can’t imagine a complete customer record without it! This should ring a bell for you: optional field for the one and mandatory for the other…
Scheduled tasks
It is probable that your system has some scheduled tasks that usually run over night. I don’t mean system-related tasks, such as database purge and reorganize. These are obviously controlled by you (the administrator).
I’m talking about application-level tasks that affect the end user: A log report, daily activity report, a warehouse balances update batch process etc. For tasks like these you should provide the user the ability to make their own schedule, since they know best their time windows.
Of course, your system might also have some down-time requirements, per day, per week or otherwise. So, giving the user the possibility to schedule their tasks can be somewhat tricky. Still, it is a necessity…
Anyway, this concludes my series of “personalization of web applications”. I hope that you found it interesting and that it gave you some food for thought. I would also like to hear your ideas on the issue, since – I’m sure – you have faced even more challenges.
Remember, the object of Personalization is to make the web system more attractive and more usable at the same time. After all, with all these systems and sites out there, you have to make a difference if you want the users to stick to your system, instead of the next guy’s.
All web systems provide some kind of search facility, be it a generic search engine that looks inside the web site and returns relevant documents or be it a search facility for the supported entities of that web system, such as “invoice search”, “loan search”, “customer search” etc.
I would bet that a user friendly search offers a whole bunch of search criteria. I would also bet that having an exhaustive list of search criteria can be overkilling for those of you that are used to work with these search engines in one (or two) specific way. For example, an accounting employee usually needs a “search customer by name” function. Nothing else. Who cares if the search engine also provides the city of residence as an additional criterion!
The mistake that a lot of developers do is that they overwhelm the user with a bunch of features and thus they achieve a level of complexity that is not welcome by some… On the other hand – yes, you are right – you just can’t have a “dummy” search with just a couple of obvious fields.
What do you do? You give the ability to the end user to save their searches. That way, low-end users will be able to just click on their saved search and the system will automatically pop-up their favorite or most common search criteria list.
Let alone the fact that you could have a fast path to “all my saved searches”. So you can present to the user all of their most-commonly used searches, in just a click. Simple, yet invaluable!
The more parametrical a system is, the more clicks and selections it will require by the user. This is perfectly understandable by you and me, but – make no mistake – the end user simply does not understand why they have to execute 15 clicks to issue a cash receipt of 15 dollars!
The name of the game is “defaults”. You should equip you system with default values for some very critical functions. Default values that can be changed by the end-user with just a click. A classical example is that of an accounting employee who – in the morning – is posting tens of accounting entries from bank statements and when they’re done with it, they start to register supplier invoices. The “bank statement” document and the “supplier invoice” document should appear automatically to them, by their selection. Imagine that for X number of documents they save exactly X clicks! A huge benefit. And your system is probably executing X less screen refreshes of the web browser. That’s… more benefit!
I’m sure that you’ve seen this before. One of your customers does not like the term “status: invoiced” and they would prefer “status: closed”. The next customer argues that “closed” means something bad and they would prefer “status: completed”. And, on top, they say “why is it so hard to change just a small word? Will it take you more than 3 seconds to do it?”. There you have it: a “simple” request which you can’t serve and thus you are becoming the cumbersome and “stick-to-your-own-ways” IT guy.
But seriously, you should consider creating a glossary of terms widely used in your system. Then, a user (or better a group of users, say those working in the same organization or company) can agree that “invoiced” can be changed to “completed”.
This is the kind of argument that a user would not raise back in the days of monstrous ERP’s of the 80’s, but in today’s world of www and SaaS, they do have increased requirements, even on the wording issue.
Have you ever seen two users that imagine the customer file structure the same way? No? Me neither! Everybody wants the screen to show different data, to hide and show fields as they wish, even to alter validation rules from one user to another.
I recently had a customer that said “the correct layout of the fields is not last-name-first but first-name-first”. Yep, I was forced to customize the customer form to show fields “the other way around” (and I did it parametrically because I didn’t want my other SaaS users to see any difference on their layout).
Therefore you need to be able to customize your screens as per the user’s requirements. Again, an accounting user cannot see why they have to enter the customer’s email, while the marketing user can’t imagine a complete customer record without it! This should ring a bell for you: optional field for the one and mandatory for the other…
It is probable that your system has some scheduled tasks that usually run over night. I don’t mean system-related tasks, such as database purge and reorganize. These are obviously controlled by you (the administrator).
I’m talking about application-level tasks that affect the end user: A log report, daily activity report, a warehouse balances update batch process etc. For tasks like these you should provide the user the ability to make their own schedule, since they know best their time windows.
Of course, your system might also have some down-time requirements, per day, per week or otherwise. So, giving the user the possibility to schedule their tasks can be somewhat tricky. Still, it is a necessity…
Anyway, this concludes my series of “personalization of web applications”. I hope that you found it interesting and that it gave you some food for thought. I would also like to hear your ideas on the issue, since – I’m sure – you have faced even more challenges.
ReplyDeleteTHANK YOU FOR THE INFORMATION
PLEASE VISIT US
erp solution providers