Wiki source code of New UI Implementation Roadmap

Last modified by Thomas Mortagne on 2017/03/24 12:27

Show last authors
1 1.1 Preamble
2
3 This document describes the proposed roadmap towards implementing the [New Watch UI>XWikiWatchNewInterface]
4
5 The options we have for implementing the UI changes are:
6 * either we start incrementally from what we have right now and end up to the desired UI
7 * 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.
8
9
10 Although the second method might be cleaner and faster, I feel that the implementation of the new UI is going to be a very long process and it would be nice to take advantages from it as soon as possible. That is why I prefer the incremental approach which can be as successful in terms of code / architecture quality provided that *we make no compromise*: we take the hard way, we rewrite components, even if there might an easier way out, we make no workarounds.
11
12 These being said, let's get on and describe the implementation flow.
13
14
15 1.1 Implementation proposal
16
17 1.1.1 Guidelines
18 * *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)
19 * *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.
20 * 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.
21 * *write tests* for data stability and consistency along with the changes that might affect it.
22 * *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).
23
24 1.1.1 Proposed flow
25
26 * start with *article list changes*: article display changes, view type changes [XWATCH-134 > https://jira.xwiki.org/browse/XWATCH-134], pagination [XWATCH-149 > https://jira.xwiki.org/browse/XWATCH-149], 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 ([XWATCH-130 > https://jira.xwiki.org/browse/XWATCH-130]) for articles can be skipped for now since it is mostly a code problem rather than a UI problem.
27 *- ~~Suggested deadline: July 30th~~
28 * 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. ##
29 #info("This can be the point where the filter model changes radically, and this must be handled right: no workarounds!\\This is the point where I suggest we implement the new event-based mechanism for communication between UI and model (see [XWATCH-83 > https://jira.xwiki.org/browse/XWATCH-83])")
30 *- ~~Suggested deadline: August 9th~~
31 * continue with *feeds tree rewriting*, with placeholders for new actions instead of the actual implementation (improving the search available engine lists, etc). #info("There will be important changes in the dialog model, triggered by this rewrite. A lot of logic that is currently implemented in dialogs and dialog wizards (feed add, feed edit, etc) must be disconnected (UI separate from model and communication must be done through a controller).")
32 *- ~~Suggested deadline: August 23rd~~
33 * 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).
34 * *new portal design and implementation*
35 * (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
36 * *create and apply new CSS* . It should be a very overridable CSS, with special care for cross browser compatibility and browser performance.
37
38 1.1.1 Notes
39 * 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.
40 * Deadlines are simple estimations, they may be changed after a discussion with $xwiki.getUserName("xwiki:XWiki.evalica").
41
42 1.1.1 Additional library requirements
43 Since 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:
44
45 * 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.
46 * 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).
47 * we abandon the use of the particular widgets, replacing them with other widgets.
48
49 I would go for options 1 & 3 for major widgets and option 2 for a good result / code report (few code, huge UI impact).

Get Connected