User:RichardBenson/Wotwewantstodotothechrome
From Open Melody
Contents
|
App UI overhaul: Our plans to change the UI for the app
Abstract
The standard chrome is a little too large at present, not Melody branded and not very flexible. Our initial objective would be a small reduction in the size of the chrome and a melody brand. Ongoing various enhancements are required to the workflow, an AJAXy app would be good. Long-term, a skinable app UI would be the eventual target.
Problem Statements
- The current chrome is MT and SA branded
- The current chrome takes up too much height
- The current chrome is fixed width
- Modification and customisation of some UI screens would enhance the posting experience
- Ajax methods should be introduced to further enhance the user flow
- Ajax methods would help eliminate unhelpful Perl error screens
- A skinnable UI would allow "white label" versions of Melody (NB: This situation should be covered in the license)
Background
Although the MT4 chrome is very slick, UI tech and understanding has improved significantly in the time since it was launched. Advances in browsers and scripting technology have enabled a new generation of stateless UI more akin to a desktop application. For Melody to stay fresh and at the cutting edge, the app UI needs to move to this sort of tech, however this will not be a quick or easy fix.
Requirements
In the short term, we need a Melody branded UI, and whilst in the CSS and HTML we can make a few amendments to the layout of the chrome and a few tweaks to the flow.
Ongoing we will need to design an application front-end and build a framework that all the screens will fit into. Once these are designed and mocked-up an assessment of the code changes required will need to be done. This is without a doubt going to be the largest phase of this project as it will undoubtedly require massive code refactoring to return JSON and callback responses instead of full HTML pages. It may be worth considering an AJAX app API that is built seperate from the main mt.cgi.
This list should be adjusted as we seek to define what we are doing for each version
Milestone 1
- Melody branded, logos and colour scheme
- Dashboard changes
- Melody news feed
Milestone 2
- User flow improvements EXPAND ME
- Expandable RTE
- Explicit "Save as draft" that doesn't refresh the page (enhancement of the auto-save)
Milestone 3
- Plugin library in-app
Milestone 4
- Desktop quickpost (AIR?)
Milestone 5
- AJAX UI
Milestone 6
- 'White Label' UI
Effect on the platform/existing features/code
The end goal is to make Melody a pleasurable place to spend time in, by reducing waiting times, providing better error catching and generally enhancing the user flow.
- Melody will use the latest technology and techniques
- App speed should be increased (after an initial load) due to less data transfer required for each action
- Adding screens will require less HTML and template inclusion
- Melody will be easier to use
This isn't going to be easy or quick and will require some major code refactoring and some pretty extreme JavaScript. We will also have to be very careful not to make it harder for plugin devs to make dialogs, app screens etc. Also, after initial release, we will undoubtedly be making some fairly quick minor point releases/bug fixes.
Effect on existing, upgrading users
Plugins that generate anything in the Chrome will somehow need to be catered for. It would be extremely foolish to cut off the massive plugin base we have available, so we will need to have an extra layer that refactors these plugin's HTML to what our JS app is expecting. Also, documentation! Maybe even a detection that this is an upgrade install, and therefore we can provide additional tooltips based around the old flow.
Effect on future new users
As long as the above mentioned abstraction layer for plugins exist, the only thing new users will need is docs. This should mostly be handled in the app with tooltips, help icons and doc links.
Project Plan
- At this stage all we concentrate on is getting 1.0 out the door, which means we need logos and style changes.
- Collect ideas for re-factoring user flow
- Start mocking up the JS app layout
Implementation Notes
Talk about the details of implementation. For example, if you've planned for a phased approach, explain how you came to those milestones and what state the code is in between each.
If Your project requires additional or later versions of infrasturcture, mention those here as well.
Resources
None yet
Project Team
Below is a list of community members participating in the project. All users are linked to their wiki user page and project leaders are marked with an asterisk.
If you are interested in participating but still not sure, add yourself to the bottom of the list. You can italicize your name if you are interested but undecided.
Related Bugs
N/A
