New UI Implementation Roadmap
Last modified byon 2017/03/24 12:27
PreambleThis document describes the proposed roadmap towards implementing the The options we have for implementing the UI changes are:
- either we start incrementally from what we have right now and end up to the desired UI
- either we rewrite the UI from scratch. Although it might seem absurd, this option stands as an option, because, sometimes it can be easier and cleaner and less error prone to rewrite / redesign than change / patch existing implementation, especially in this case, where the UI redesign triggers a lot of code / architecture changes.
- start with ergonomics and structure changes rather than aspect and graphics changes. Have all new interaction set in place with current visual aspect and then change the visuals. We might work harder for maintenance, but this makes it more iterative (see next bullet)
- implement component by component even if there might be cross-component aspects which must be implemented for multiple widgets, follow the agile principle and have deliverable implementations at each iteration.
- take time to do all architecture changes correctly and clean (there will be some major changes). What cannot be implemented, should at least be reported on jira so that we don't forget about it.
- write tests for data stability and consistency along with the changes that might affect it.
- performance primes over aspect: DOM manipulation and applying CSS can get very lazy depending on the browser and operating system (see IE6, Firefox under Ubuntu, etc).
- start with article list changes: article display changes, view type changes
, pagination , leaving the article action changes (add tag, add comment) at the end, as they might impact the controller / model and require code changes across multiple classes. Bulk actions implementation ( ) for articles can be skipped for now since it is mostly a code problem rather than a UI problem.
- Suggested deadline: July 30th
- continue with filter bar rewriting. This would trigger important model changes as some of the filters will disappear (keywords, for example) and some others are created (the concept of a saved filter). Follow the same incremental approach for implementing the multiple panels in the bar.
- Suggested deadline: August 9th
- continue with feeds tree rewriting, with placeholders for new actions instead of the actual implementation (improving the search available engine lists, etc).
- Suggested deadline: August 23rd
- actions and views should be moved from their current place (press review generation, text analysis, loading status display, etc) at the moment when they are needed in their new positions (when the component that would hold them in the new design is implemented). Make sure that this will be a move process and not a copy process (actions should at no point be duplicated unless this is the desired behavior).
- new portal design and implementation
- (potentially) design and implementation of the administration page / placeholder, as described in http://xwiki.markmail.org/search/?q=new%20UI%20Proposal#query:new%20UI%20Proposal+page:1+mid:wtgnmqjzwpnwbecc+state:results
- create and apply new CSS . It should be a very overridable CSS, with special care for cross browser compatibility and browser performance.
- I feel that all the code changes will increase the size and the responsibility of the controller class (com.xpn.xwiki.watch.client.Watch) will become even more large and hairy. We should keep an eye on it and prevent such situations.
- Deadlines are simple estimations, they may be changed after a discussion with .
Additional library requirementsSince not all the widgets designed in the UI proposal exist in GWT or the libraries currently used by Watch (GWT-Widget at http://gwt-widget.sourceforge.net/), we need to find a solution for this for which we have the following options:
- we add new libraries in the Watch dependencies. It must be an opensource library (wishfully committed to open source), stable enough, with a nice community and development team, active enough -- potential bugs must be able to get a response pretty quick (maybe a fix) and the lib should not prevent a potential update to GWT 1.5.
- we write the widgets with the tools we have. This is not an option if the code is too large and there is a library alternative on the market as we would both reinvent the wheel and write loads of code for us to maintain (instead of library dev teams).
- we abandon the use of the particular widgets, replacing them with other widgets.