Like I answered to Taher (and indirectly to Sharan and ideas shared at Seville) 
it's a long term plan.

I must also add that without applying a such plan OFBiz will slowly fading in 
history

We all agree it deserves better :)

Jacques


Le 28/11/2016 à 14:19, gil portenseigne a écrit :
Hello,

I really like the idea of separate HTML/UI stuff from framework where it does not belong. This kind of separation could offer easier and less intrusive alternative to implement different UI technology for OFBiz, and even hot-switch between them.

From my point of view, this done, anyone could deploy a solution with its own 
technology and contribute it back to the community with ease.

But defining standard graphic charter for screens is really important and needed to get consistency, allowing each theme to behave its own way on defined screen types.

Also creating new components that will provide simplified, standardized and easy usable processes will enhance adoptability of OFbiz, since it will behave as a ready to use *demo* component.
These new components could be the default ones introduced to new user, to show 
the capability of OFBiz to render simple and clean screens.

Then the existing components could be kept as "Developper ShowCase Screens", 
that introduce every functionalities available in OFBiz.

Thanks and regards

Gil


On 28/11/2016 11:28, Sharan Foga wrote:
Hi Everyone

Another one of the topics that came up during the brainstorming in Seville was around the UI. In fact we had at least 2 presentations from the OFBiz track at Apachecon that were about how we could improve our UI.

If the UI was the main focus - what could the strategy look like
- User Interface - have 2 versions of the UI, one very clean and simple, the 
other more advanced. (Our current UI could be the advanced one....?
- Separate the web part from the widgets
- We have too many fields on one screen (many of them are not mandatory and are just included as optional). What if we slimmed down all the screens to have a sensible default UI for users. The UI could also be modifiable by service providers. Simplify the screens with defaults
- Use Bootstrap / CSS / Angular
- Isolate web related
- Define a graphics charter to be used for the screens
- Have a CSS convention
- Remove web from the framework - it shouldn't be there

What do people think?

-Do people think it would be a good idea to have 2 versions of the UI? (a 
simple one and a more advanced one?)

- Are these the things we would need to focus on or have in place if we wanted 
to focus on the UI?

(Also I know Nicolas has mentioned that he has already started work on a Proof of Concept for a common theme - so do we need to make sure we agree conventions etc before much more work is done?)

Thanks
Sharan


Reply via email to