After you have built the initial version of a web application, it can be hard to know what to add in version 2.0, tricky to know how add value and make it expensive software , and near-impossible to understand what features a web 2.0 application actually has. This article describes some common features that you might think are merely Nice To Have, and why you might really need them sooner rather than later.
The following features are most relevant for a public Internet web application that people use to organise some set of data, in collaboration with each other. Your mileage may vary for other kinds of applications.
- Data management features : success messages, fewer required fields, data input validation, data validation warnings.
- Software integration features : OpenSearch API for queries, iCalendar URLs for date-related data, KML URLs for geographic data, export data to a file, import data from a file.
- Collaboration features : comments, tags, change notifications, recent changes.
- User-interface features : dashboard, favourites, edit-in-place.
Data management features
Better data management features are mostly about supporting user needs for data entry, instead of attempting to dictate how someone uses your software: let the user do what they want, and tell them what is going on.
Success messages
Show a success message at the top of the page after the user has successfully made a permanent change to some data. Use a green tick icon, and be specific about what changed.
This is an improvement on the standard behaviour, which should be to show a page that includes the updated data, because this makes it more explicit which data changed. It also supports the case when there is no new version of the data to see, such as when you delete something. This may also be helpful in making the user realise that they have made a permanent change when they did not think they had.
For example, LinkedIn shows this success message after you send an invitation to someone.
Fewer required fields
Allow users to enter incomplete data, so that missing data does not break the system. Remind the user that the data is incomplete; ask nicely for the rest.
You may want users to enter certain information, but you probably cannot force them to. People are likely to be cleverer than your software, and if users just type ‘unknown’ into required fields, you have gained nothing other than annoyed users. Besides, some users will always be able to avoid entering data in your software by simply not using it.
Instead, let your users input incomplete information, so they can go to lunch without finishing a data-entry task, and make sure your software can handle this case.
Data input validation
Handle typos by validating input data; show a validation error for user-entered data that could not possibly be correct. Be careful not to be too strict.
It is usually a good idea not to be over-zealous with input validation. It is a good idea to reject obviously wrong values, because there are some mistakes that you can spot. For example, if some enters ‘197? as their year of birth (or their age) then you can be sure that this was not intentional.
On the other hand, there is probably always someone with an address or name format that you did not expect, and they are likely to be annoyed if you reject their input. For example, 37signals staff were not impressed by the error “Your Employer Name cannot contain any numbers” :
Draconian validation may seem justified in the name of data quality, but even if it does achieve that it will probably do so at the price of having far less data in the first place.
Data validation warnings
When displaying data, warn the user about likely problems or gaps in the data.
If you allow incomplete data, then you may need to warn the user about the consequences. For example, an Amazon wish-list without a delivery address shows the warning ‘Please enter a delivery address so that items on this list can be bought by others and sent to you.’ This is helpful for the list of presents that friends and family can buy me, but I do not want my fans to buy me computer books that my employer will pay for so it would be annoying if an address were required.
Data warnings can also add more explanation to how your software works. Instead of a missing value, you can explain that ‘Shipping costs cannot be calculated until you enter a delivery address’ .
Finally, you can warn the user about inconsistent data, when you do not know which value is wrong. For example, if the user enters a price of ?100 and VAT (sales tax) of ?2000 then one of the amounts has to be wrong, but it could be either one.
Software integration features
People who use software to get a job done, especially business software, are frequently frustrated that they cannot get data from one system to another. This day-to-day frustration becomes more serious and even less welcome in data management applications that lock the data in, making it hard or impossible to migrate the data to some other software. Data is more useful when you can do more with it, so data management software is more useful when you can get the data out.
OpenSearch API for queries
Implement the OpenSearch API so that other software can perform queries and display the results, including search interfaces.
For example, Firefox 2 and Internet Explorer 7 can add OpenSearch providers to their search interface, so you can search the browser’s search field. Alternatively, other web applications could use this and other APIs in your software to mash-up your data with data from other applications.
扫一扫
82
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
