For purposes of both user acceptance/reduction of technical complexity, rules regarding the use of web-parts on a page should now be enforced for our model:
1) No more than six web-parts on a page by default. The user may well be able to add more web-parts from a gallery but this should be at his/her discretion. By default, any more than six on a page risks disorientation.
2) Web-part communication only goes one way. Although certainly technically possible to have web-parts communicate both ways, i.e. both to and from each other. This creates unnecessary complexity i.e. users have to think modally also it increases the number of paths through the system which then have to be tested.
3) One web-part should communicate with a maximum of two other web-parts. Although generally desirable to have web-parts communicating with each other, any more than two other web-parts being “automatically” changed when a user selects an item in a third web-part is making the application too linear i.e. it prevents other activity from happening in parallel because UX components have just been re-purposed for the current task under consideration. Allowing for a level of UX multi-tasking is desirable.
4) No more than one Display/Update web-part per page. Any more than this would entail either a significant amount of scrolling or would be confusing to the user as two portions of the screen would then be devoted to displayed information. Which Display/Update web-part should they look at, for example, when the user selects a contextual data item from a Type/Filter?
Another rule is that the look and feel of web-parts and the way that they interact should be consistent. This benefits not only rapid development, in that UX code may be developed once and re-used for varying functions but also significantly reduces testing and training time.
No comments:
Post a Comment