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 |
As discussed here: http://ofbiz.135035.n4.nabble.com/OFBiz-Premier-League-Reviewers-Choice-Award-tp4699250p4699699.html
I think that is a pretty good idea. Good luck |
In reply to this post by Sharan Foga
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 |
In reply to this post by Paul Piper
Troll inside: it's easier to increase the UI in its own corner instead
of sharing with other, sure. But the work is in progress and maybe you could try to participate with a good spirit :) Regards Nicolas Le 28/11/2016 à 11:20, Paul Piper a écrit : > As discussed here: > http://ofbiz.135035.n4.nabble.com/OFBiz-Premier-League-Reviewers-Choice-Award-tp4699250p4699699.html > > I think that is a pretty good idea. Good luck > > > > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/DISCUSSION-Improving-the-OFBiz-User-Interface-tp4699708p4699709.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. > |
That wasn't meant as trolling, Nicolas. It is a good idea and absolutely needed. Perhaps as a cautious advice: your problem is going to be standardization, more so than the UI.
The html in stock ofbiz is a mess and the apps don't really share a common pattern. For Scipio ERP we cleaned it all up, which took weeks by itself before we were even able to start on anything useful. Besides that, you will have to think about the difference in development techniques used. Some apps rely on *widgets, others on plain ftl. Whatever approach you choose, you will have to either reimplement all apps, or take care of these differences. |
Hi Paul, Nice point, i really think you're right about standardization, and that will be a very important step to write down and to ensure it will be well used/updated in future implementations. And indeed it will be huge
work to migrate all component to this standardization, and will
be easier to write down from scratch new standardized
components. Thanks, Gil On 28/11/2016 21:39, Paul Piper wrote:
That wasn't meant as trolling, Nicolas. It is a good idea and absolutely needed. Perhaps as a cautious advice: your problem is going to be standardization, more so than the UI. The html in stock ofbiz is a mess and the apps don't really share a common pattern. For Scipio ERP we cleaned it all up, which took weeks by itself before we were even able to start on anything useful. Besides that, you will have to think about the difference in development techniques used. Some apps rely on *widgets, others on plain ftl. Whatever approach you choose, you will have to either reimplement all apps, or take care of these differences. -- View this message in context: http://ofbiz.135035.n4.nabble.com/DISCUSSION-Improving-the-OFBiz-User-Interface-tp4699708p4699747.html Sent from the OFBiz - Dev mailing list archive at Nabble.com. |
Hi Sharan and All,
I believe this is a very important topic. The user interface is the weakest part in OFBiz and I think we should focus our attention on it. Based on your points discussed above and our brainstorming session in Apachecon I suggest we start with the following initiatives: - Create a base theme. This theme would be raw (no colors, no design) that just works and renders things correctly. It also houses the low-level libraries and utilities shared among the themes (e.g. bootstrap, jQuery, etc ...). In addition, this theme would also house a unified FTL macro library to render _everything_ - Create at least one higher level theme based on the above mentioned base theme. - Modify the widget system to allow the creation of custom widgets. A custom widget can then be implemented _outside_ the framework (in the theme itself, or whatever user interface you choose like swing or FOP) - Create a component (we can call it backend or something like that) that provides all the back-end user interfaces for managing the system. The critical part here is to have _zero_ FTL, HTML, CSS or JavaScript in this component. All the web stuff should reside in the themes and the widgets remain a pure DSL. The current user interface is full of <platform-specific ...> tags for dropping in freemarker templates. So refactoring would be a huge pain. A fresh start makes sense and that's why I make the above proposition. Ideas? Thoughts? Cheers, Taher Alkhateeb On Tue, Nov 29, 2016 at 12:25 AM, gil portenseigne < [hidden email]> wrote: > Hi Paul, > > Nice point, i really think you're right about standardization, and that > will be a very important step to write down and to ensure it will be well > used/updated in future implementations. > > And indeed it will be huge work to migrate all component to this > standardization, and will be easier to write down from scratch new > standardized components. > > Thanks, > > Gil > On 28/11/2016 21:39, Paul Piper wrote: > > That wasn't meant as trolling, Nicolas. It is a good idea and absolutely > needed. Perhaps as a cautious advice: your problem is going to be > standardization, more so than the UI. > > The html in stock ofbiz is a mess and the apps don't really share a common > pattern. For Scipio ERP we cleaned it all up, which took weeks by itself > before we were even able to start on anything useful. Besides that, you will > have to think about the difference in development techniques used. Some apps > rely on *widgets, others on plain ftl. Whatever approach you choose, you > will have to either reimplement all apps, or take care of these differences. > > > > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/DISCUSSION-Improving-the-OFBiz-User-Interface-tp4699708p4699747.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. > > > |
Administrator
|
I like (all) the ideas, but that sounds like a long term plan :)
Jacques Le 28/11/2016 à 23:02, Taher Alkhateeb a écrit : > Hi Sharan and All, > > I believe this is a very important topic. The user interface is the weakest > part in OFBiz and I think we should focus our attention on it. Based on > your points discussed above and our brainstorming session in Apachecon I > suggest we start with the following initiatives: > > - Create a base theme. This theme would be raw (no colors, no design) that > just works and renders things correctly. It also houses the low-level > libraries and utilities shared among the themes (e.g. bootstrap, jQuery, > etc ...). In addition, this theme would also house a unified FTL macro > library to render _everything_ > - Create at least one higher level theme based on the above mentioned base > theme. > - Modify the widget system to allow the creation of custom widgets. A > custom widget can then be implemented _outside_ the framework (in the theme > itself, or whatever user interface you choose like swing or FOP) > - Create a component (we can call it backend or something like that) that > provides all the back-end user interfaces for managing the system. The > critical part here is to have _zero_ FTL, HTML, CSS or JavaScript in this > component. All the web stuff should reside in the themes and the widgets > remain a pure DSL. > > The current user interface is full of <platform-specific ...> tags for > dropping in freemarker templates. So refactoring would be a huge pain. A > fresh start makes sense and that's why I make the above proposition. > > Ideas? Thoughts? > > Cheers, > > Taher Alkhateeb > > On Tue, Nov 29, 2016 at 12:25 AM, gil portenseigne < > [hidden email]> wrote: > >> Hi Paul, >> >> Nice point, i really think you're right about standardization, and that >> will be a very important step to write down and to ensure it will be well >> used/updated in future implementations. >> >> And indeed it will be huge work to migrate all component to this >> standardization, and will be easier to write down from scratch new >> standardized components. >> >> Thanks, >> >> Gil >> On 28/11/2016 21:39, Paul Piper wrote: >> >> That wasn't meant as trolling, Nicolas. It is a good idea and absolutely >> needed. Perhaps as a cautious advice: your problem is going to be >> standardization, more so than the UI. >> >> The html in stock ofbiz is a mess and the apps don't really share a common >> pattern. For Scipio ERP we cleaned it all up, which took weeks by itself >> before we were even able to start on anything useful. Besides that, you will >> have to think about the difference in development techniques used. Some apps >> rely on *widgets, others on plain ftl. Whatever approach you choose, you >> will have to either reimplement all apps, or take care of these differences. >> >> >> >> -- >> View this message in context: http://ofbiz.135035.n4.nabble.com/DISCUSSION-Improving-the-OFBiz-User-Interface-tp4699708p4699747.html >> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >> >> >> |
Administrator
|
In reply to this post by Gil Portenseigne
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 > |
Administrator
|
In reply to this post by Gil Portenseigne
Le 28/11/2016 à 14:19, gil portenseigne a écrit :
> > 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 Gil, I believe this is what David kinda did for/with Moqui. I also believe that having our own Maven repository for plugins is the 1st step in this process. For that we need to complete/enhance the current plugin mechanism (OFBIZ-8251) Then we can create our own Maven repository on the demo server. I already spoke about that at https://issues.apache.org/jira/browse/OFBIZ-9123?focusedCommentId=15687651&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15687651 Summary: <<Now I'm more and more thinking about plugins and specialpurpose. When the pushPlugin Gradle task will be completed (not only in localhost), I'd prefer to have plugins available in an OFBiz common Maven repo (on our demo VM for instance). Then some of the current specialpurpose components and new components plugins would be maintained by their contributors>> Jacques |
In reply to this post by Paul Piper
Completely Paul for the standardization.
Currently we try to go out all ftl templating from framework to push on theme with the purpose to have only the screen logic on the framework. All the rendering would be define and surcharge on the theme. But standardization on what ? We have different classification on screen like : * dedicate screen EventMessages, geoChart, countries * main decorator screen : GlobalDecorator, LookupDecorator, SimpleDecorator * embed decorator screen : FindScreenDecorator My idea like sharing with Julien, Gil and Taher would be to define these different standard screen as an API you can be use to structure a screen as guideline. If the API screen is strong, the theme can rendering it as a like, and each contributer can create a theme and keep the coherence. Yes it's a long work but the better way it's start with good base. Nicolas Le 28/11/2016 à 21:39, Paul Piper a écrit : > That wasn't meant as trolling, Nicolas. It is a good idea and absolutely > needed. Perhaps as a cautious advice: your problem is going to be > standardization, more so than the UI. > > The html in stock ofbiz is a mess and the apps don't really share a common > pattern. For Scipio ERP we cleaned it all up, which took weeks by itself > before we were even able to start on anything useful. Besides that, you will > have to think about the difference in development techniques used. Some apps > rely on *widgets, others on plain ftl. Whatever approach you choose, you > will have to either reimplement all apps, or take care of these differences. > > > > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/DISCUSSION-Improving-the-OFBiz-User-Interface-tp4699708p4699747.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. > |
In reply to this post by Sharan Foga
Hi Sharan, everyone,
It was idea like seed that start to grow up in my mind since I start with OFBiz. Today, after several try on the project I think the community is very closed to find the best way to improve the UI. The first sharing was with Gil and Nicolas, then we decide to submit a talk about that. The big surprise was that Taher have the quite same ideas than us !!! There are many things that must be done to have a good UI. - All the UI could be managed by the theme without modifying the framework. - Each screen must be linked to a screen structure. - We need a UI standard that the developer need to follow for screen creation. - We must have a common theme (remove all theming stuff from the framework) - It could be interesting to have a new component to improve / test a new theme - We have to create at least a new theme without limits ! Be crazy ! It's a long term project, but it must be our concern, all the people that want a beautiful and UX UI must be involved \o/ I remember when I start bootstrap topics, that we were many ;) This project is more ambitious, a long term one that will improve the theming automatism to provide to the webdesigner an unlimited tool and, in the same time, an easy to maintain framework for us ;) Why we need a new component to test new theme ? When I start working with OFBiz, I was so surprised that the UI is too heavy. Then I was thinking that I have to improve the UI to provide a best one. After several try I understand that the actual UI is not a final user interface. It is a developer one. It's a developer UI because it contain all the features developed. But definitively, we can't provide this kind of UI to final users, we have to simplify it. In the same times, we can't delete the current UI because developers need to improve it with new features that will help us to deploy new features to our final users. For this new component, we can implement an existing component but simplified and ready for the new theme(s). In conclusion, if the new component dedicated for test a new theme match to the community needs, Taher think to a super simplified developer user interface that facilitate developers to improve the software. A new interface without any constraint that allow developers to develop easily new features. What about the new theme ? A new theme, maybe more than one theme. It could be crazy but if we need to be sure that we can do anything we want and that the screen structure allow webdesigner to do whatever we want, we can imagine 2 new themes exactly different in structure :) I have at least an idea, just for the look and feel. I can share it and we can improve it all together (or just scrap it and start with a new idea ^^). In the same times, at the Apache Con we meet Victoria Bondarchuk <http://events.linuxfoundation.org/events/apachecon-europe/program/schedule> (work in UX project management) that want to help us in this task, and Darshan Kumar (work also in UX) who want to join the OFBiz project starting on that task. How to start ? I propose to start by creating a main Jira about Improve the UI (maybe this one already exist since a long long time ago ^^) and then link all the subtasks to this main one. Maybe we can start a topic by subtask to share with the community. Before creating anything it could be interesting to have opinion of all people who want UI changes. All the community I think, so I hope server will not be down because of the OFBiz community involving ^^ I hope Paul, Gaurav and all the people that try or already improve the UI will help on this task \o/ I want to be an actor of this changes and I hope you want it too ! Thanks for all your help in advance. Julien. 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 > |
Administrator
|
Hi Julien,
Just few questions inline Le 29/11/2016 à 23:35, Julien NICOLAS a écrit : > Hi Sharan, everyone, > > It was idea like seed that start to grow up in my mind since I start with OFBiz. Today, after several try on the project I think the community is > very closed to find the best way to improve the UI. > > The first sharing was with Gil and Nicolas, then we decide to submit a talk about that. The big surprise was that Taher have the quite same ideas > than us !!! > > There are many things that must be done to have a good UI. > > - All the UI could be managed by the theme without modifying the framework. > > - Each screen must be linked to a screen structure. What would be this screen structure? You don't need to develop much at this stage, just that I can't vision what it would be. > > - We need a UI standard that the developer need to follow for screen creation. > > - We must have a common theme (remove all theming stuff from the framework) > > - It could be interesting to have a new component to improve / test a new theme > > - We have to create at least a new theme without limits ! Be crazy ! > > It's a long term project, but it must be our concern, all the people that want a beautiful and UX UI must be involved \o/ I remember when I start > bootstrap topics, that we were many ;) > > This project is more ambitious, a long term one that will improve the theming automatism to provide to the webdesigner an unlimited tool and, in the > same time, an easy to maintain framework for us ;) > > > Why we need a new component to test new theme ? > > When I start working with OFBiz, I was so surprised that the UI is too heavy. Then I was thinking that I have to improve the UI to provide a best > one. After several try I understand that the actual UI is not a final user interface. It is a developer one. It's a developer UI because it contain > all the features developed. But definitively, we can't provide this kind of UI to final users, we have to simplify it. In the same times, we can't > delete the current UI because developers need to improve it with new features that will help us to deploy new features to our final users. > > For this new component, we can implement an existing component but simplified and ready for the new theme(s). You mean we could take and existing component, say example for instance, and would simply it at the UI level. I picked example because it's already rather simple and contains demonstration of features. > > In conclusion, if the new component dedicated for test a new theme match to the community needs, Taher think to a super simplified developer user > interface that facilitate developers to improve the software. A new interface without any constraint that allow developers to develop easily new > features. > Another thing I can't vision at this stage, no hurry, I guess I'll later :) All the rest is OK with me, or at least I think I did grab the ideas Thanks! Jacques > > What about the new theme ? > > A new theme, maybe more than one theme. It could be crazy but if we need to be sure that we can do anything we want and that the screen structure > allow webdesigner to do whatever we want, we can imagine 2 new themes exactly different in structure :) > > I have at least an idea, just for the look and feel. I can share it and we can improve it all together (or just scrap it and start with a new idea > ^^). In the same times, at the Apache Con we meet Victoria Bondarchuk <http://events.linuxfoundation.org/events/apachecon-europe/program/schedule> > (work in UX project management) that want to help us in this task, and Darshan Kumar (work also in UX) who want to join the OFBiz project starting > on that task. > > > How to start ? > > I propose to start by creating a main Jira about Improve the UI (maybe this one already exist since a long long time ago ^^) and then link all the > subtasks to this main one. Maybe we can start a topic by subtask to share with the community. > > > Before creating anything it could be interesting to have opinion of all people who want UI changes. All the community I think, so I hope server will > not be down because of the OFBiz community involving ^^ > > I hope Paul, Gaurav and all the people that try or already improve the UI will help on this task \o/ > > I want to be an actor of this changes and I hope you want it too ! > > Thanks for all your help in advance. > > Julien. > > > 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 >> > > |
Hi Jacques,
On 30/11/2016 08:51, Jacques Le Roux wrote: > Hi Julien, > > Just few questions inline > > > Le 29/11/2016 à 23:35, Julien NICOLAS a écrit : >> Hi Sharan, everyone, >> >> It was idea like seed that start to grow up in my mind since I start >> with OFBiz. Today, after several try on the project I think the >> community is very closed to find the best way to improve the UI. >> >> The first sharing was with Gil and Nicolas, then we decide to submit >> a talk about that. The big surprise was that Taher have the quite >> same ideas than us !!! >> >> There are many things that must be done to have a good UI. >> >> - All the UI could be managed by the theme without modifying the >> framework. >> >> - Each screen must be linked to a screen structure. > > What would be this screen structure? You don't need to develop much at > this stage, just that I can't vision what it would be. theme. For example, the find screen can be define as : - A research field area - A result area If all the find screen could be linked to this structure, it will be easier for theme to manage it's own template of search screen. It will be included in the main decorator that will also linked to a structure, so theme can manage to change the template. And when you change the theme, it could be a completely different look and feel :) I hope I explain well my thought. > >> >> - We need a UI standard that the developer need to follow for screen >> creation. >> >> - We must have a common theme (remove all theming stuff from the >> framework) >> >> - It could be interesting to have a new component to improve / test >> a new theme >> >> - We have to create at least a new theme without limits ! Be crazy ! >> >> It's a long term project, but it must be our concern, all the people >> that want a beautiful and UX UI must be involved \o/ I remember when >> I start bootstrap topics, that we were many ;) >> >> This project is more ambitious, a long term one that will improve the >> theming automatism to provide to the webdesigner an unlimited tool >> and, in the same time, an easy to maintain framework for us ;) >> >> >> Why we need a new component to test new theme ? >> >> When I start working with OFBiz, I was so surprised that the UI is >> too heavy. Then I was thinking that I have to improve the UI to >> provide a best one. After several try I understand that the actual UI >> is not a final user interface. It is a developer one. It's a >> developer UI because it contain all the features developed. But >> definitively, we can't provide this kind of UI to final users, we >> have to simplify it. In the same times, we can't delete the current >> UI because developers need to improve it with new features that will >> help us to deploy new features to our final users. >> >> For this new component, we can implement an existing component but >> simplified and ready for the new theme(s). > > You mean we could take and existing component, say example for > instance, and would simply it at the UI level. I picked example > because it's already rather simple and contains demonstration of > features. we start to re-implement (using the existing services) but in a more simple way (without all the features, selecting only the main ones). > >> >> In conclusion, if the new component dedicated for test a new theme >> match to the community needs, Taher think to a super simplified >> developer user interface that facilitate developers to improve the >> software. A new interface without any constraint that allow >> developers to develop easily new features. >> > > Another thing I can't vision at this stage, no hurry, I guess I'll > later :) I'll do it soon ^^ > > All the rest is OK with me, or at least I think I did grab the ideas > > Thanks! > > Jacques > >> >> What about the new theme ? >> >> A new theme, maybe more than one theme. It could be crazy but if we >> need to be sure that we can do anything we want and that the screen >> structure allow webdesigner to do whatever we want, we can imagine 2 >> new themes exactly different in structure :) >> >> I have at least an idea, just for the look and feel. I can share it >> and we can improve it all together (or just scrap it and start with a >> new idea ^^). In the same times, at the Apache Con we meet Victoria >> Bondarchuk >> <http://events.linuxfoundation.org/events/apachecon-europe/program/schedule> >> (work in UX project management) that want to help us in this task, >> and Darshan Kumar (work also in UX) who want to join the OFBiz >> project starting on that task. >> >> >> How to start ? >> >> I propose to start by creating a main Jira about Improve the UI >> (maybe this one already exist since a long long time ago ^^) and then >> link all the subtasks to this main one. Maybe we can start a topic by >> subtask to share with the community. >> >> >> Before creating anything it could be interesting to have opinion of >> all people who want UI changes. All the community I think, so I hope >> server will not be down because of the OFBiz community involving ^^ >> >> I hope Paul, Gaurav and all the people that try or already improve >> the UI will help on this task \o/ >> >> I want to be an actor of this changes and I hope you want it too ! >> >> Thanks for all your help in advance. >> >> Julien. >> >> >> 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 >>> >> >> > > |
Amazing discussion and initiative.
My only recommendation at the moment is to try to plan very short (in scope and in time) development cycles (requirements gathering and discussion, design, implementation, review) so that each cycle could focus on a specific experiment/proposal (e.g. a given ui technology) and could deliver a proof of concept to the community (e.g. as a new component) for further discussion and work. In this way we will be able to quickly implement and compare different solutions/technologies and will have a chance to take a more informed decision. Jacopo |
Good point Jacopo. We need a place to collaborate and get down to business.
I would prefer an interactive HipChat session to get rolling and decide what to do next, then maybe create a wiki page or something like that based on the initial plan. On Wed, Nov 30, 2016 at 1:07 PM, Jacopo Cappellato < [hidden email]> wrote: > Amazing discussion and initiative. > My only recommendation at the moment is to try to plan very short (in > scope and in time) development cycles (requirements gathering and > discussion, design, implementation, review) so that each cycle could focus > on a specific experiment/proposal (e.g. a given ui technology) and could > deliver a proof of concept to the community (e.g. as a new component) for > further discussion and work. > > In this way we will be able to quickly implement and compare different > solutions/technologies and will have a chance to take a more informed > decision. > > Jacopo > |
In reply to this post by Jacopo Cappellato-5
Yes, I agree, let's make it simple for the POC.
On 30/11/2016 11:07, Jacopo Cappellato wrote: > Amazing discussion and initiative. > My only recommendation at the moment is to try to plan very short (in > scope and in time) development cycles (requirements gathering and > discussion, design, implementation, review) so that each cycle could focus > on a specific experiment/proposal (e.g. a given ui technology) and could > deliver a proof of concept to the community (e.g. as a new component) for > further discussion and work. > > In this way we will be able to quickly implement and compare different > solutions/technologies and will have a chance to take a more informed > decision. > > Jacopo > |
Hello Everyone,
Looks like I am jumping a bit late here. But as Julien said I am really interested on working on the UI side of the project. I am still looking deep into the ofbiz structure and understand how Julien is proposing to do UI customisation so I can help and make OFBiz look good :) For starting what I am able to understand and quickly start is prepare a theme for the e-commerce component that is responsive in nature and with good UI/UX components. So, anyone starting with ofbiz can directly use the theme with minor changes according to need. Just to mention, I have updated my angular code to github which i presented in presentation at ApacheCON. I have already posting link on hipchat, if somebody interested can look into it. I was interested in using angular as all together different single page app outside ofbiz because it helped me do good amount of UI customisation and on the other hand for small modules or some specific requirement it was really light-weight to use at client's end. https://github.com/gauravsaini03/ofbiz-angular Thanks Gaurav On Wed, Nov 30, 2016 at 6:54 PM, Julien NICOLAS <[hidden email]> wrote: > Yes, I agree, let's make it simple for the POC. > > > > On 30/11/2016 11:07, Jacopo Cappellato wrote: > >> Amazing discussion and initiative. >> My only recommendation at the moment is to try to plan very short (in >> scope and in time) development cycles (requirements gathering and >> discussion, design, implementation, review) so that each cycle could focus >> on a specific experiment/proposal (e.g. a given ui technology) and could >> deliver a proof of concept to the community (e.g. as a new component) for >> further discussion and work. >> >> In this way we will be able to quickly implement and compare different >> solutions/technologies and will have a chance to take a more informed >> decision. >> >> Jacopo >> >> > -- Regards, *Gaurav Saini* |
You talking about something like
- [1], which is bootstrap based and intended for customer facing apps (e.g. cmssite and ecommerce variants), - [2], which is current default ecommerce theme elements disentangled from the framework stack ? [1] https://github.com/ORRTIZ/ecbootstrap [2] https://github.com/ORRTIZ/ecdefault Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Wed, Nov 30, 2016 at 8:06 PM, Gaurav Saini <[hidden email]> wrote: > Hello Everyone, > > Looks like I am jumping a bit late here. But as Julien said I am really > interested on working on the UI side of the project. I am still looking > deep into the ofbiz structure and understand how Julien is proposing to do > UI customisation so I can help and make OFBiz look good :) > > For starting what I am able to understand and quickly start is prepare a > theme for the e-commerce component that is responsive in nature and with > good UI/UX components. So, anyone starting with ofbiz can directly use the > theme with minor changes according to need. > > Just to mention, I have updated my angular code to github which i presented > in presentation at ApacheCON. I have already posting link on hipchat, if > somebody interested can look into it. I was interested in using angular as > all together different single page app outside ofbiz because it helped me > do good amount of UI customisation and on the other hand for small modules > or some specific requirement it was really light-weight to use at client's > end. > https://github.com/gauravsaini03/ofbiz-angular > > Thanks > Gaurav > > > On Wed, Nov 30, 2016 at 6:54 PM, Julien NICOLAS <[hidden email] > > > wrote: > > > Yes, I agree, let's make it simple for the POC. > > > > > > > > On 30/11/2016 11:07, Jacopo Cappellato wrote: > > > >> Amazing discussion and initiative. > >> My only recommendation at the moment is to try to plan very short (in > >> scope and in time) development cycles (requirements gathering and > >> discussion, design, implementation, review) so that each cycle could > focus > >> on a specific experiment/proposal (e.g. a given ui technology) and could > >> deliver a proof of concept to the community (e.g. as a new component) > for > >> further discussion and work. > >> > >> In this way we will be able to quickly implement and compare different > >> solutions/technologies and will have a chance to take a more informed > >> decision. > >> > >> Jacopo > >> > >> > > > > > -- > Regards, > *Gaurav Saini* > |
Right, looks like it doesn't have entire features covered from the demo
page I saw. But yes on similar tracks we can build something really good to go. Thanks Gaurav On Thu, Dec 1, 2016 at 1:08 AM, Pierre Smits <[hidden email]> wrote: > You talking about something like > > - [1], which is bootstrap based and intended for customer facing apps > (e.g. cmssite and ecommerce variants), > - [2], which is current default ecommerce theme elements disentangled > from the framework stack > > ? > > [1] https://github.com/ORRTIZ/ecbootstrap > [2] https://github.com/ORRTIZ/ecdefault > > Best regards, > > Pierre Smits > > ORRTIZ.COM <http://www.orrtiz.com> > OFBiz based solutions & services > > OFBiz Extensions Marketplace > http://oem.ofbizci.net/oci-2/ > > On Wed, Nov 30, 2016 at 8:06 PM, Gaurav Saini <[hidden email]> > wrote: > > > Hello Everyone, > > > > Looks like I am jumping a bit late here. But as Julien said I am really > > interested on working on the UI side of the project. I am still looking > > deep into the ofbiz structure and understand how Julien is proposing to > do > > UI customisation so I can help and make OFBiz look good :) > > > > For starting what I am able to understand and quickly start is prepare a > > theme for the e-commerce component that is responsive in nature and with > > good UI/UX components. So, anyone starting with ofbiz can directly use > the > > theme with minor changes according to need. > > > > Just to mention, I have updated my angular code to github which i > presented > > in presentation at ApacheCON. I have already posting link on hipchat, if > > somebody interested can look into it. I was interested in using angular > as > > all together different single page app outside ofbiz because it helped me > > do good amount of UI customisation and on the other hand for small > modules > > or some specific requirement it was really light-weight to use at > client's > > end. > > https://github.com/gauravsaini03/ofbiz-angular > > > > Thanks > > Gaurav > > > > > > On Wed, Nov 30, 2016 at 6:54 PM, Julien NICOLAS < > [hidden email] > > > > > wrote: > > > > > Yes, I agree, let's make it simple for the POC. > > > > > > > > > > > > On 30/11/2016 11:07, Jacopo Cappellato wrote: > > > > > >> Amazing discussion and initiative. > > >> My only recommendation at the moment is to try to plan very short (in > > >> scope and in time) development cycles (requirements gathering and > > >> discussion, design, implementation, review) so that each cycle could > > focus > > >> on a specific experiment/proposal (e.g. a given ui technology) and > could > > >> deliver a proof of concept to the community (e.g. as a new component) > > for > > >> further discussion and work. > > >> > > >> In this way we will be able to quickly implement and compare different > > >> solutions/technologies and will have a chance to take a more informed > > >> decision. > > >> > > >> Jacopo > > >> > > >> > > > > > > > > > -- > > Regards, > > *Gaurav Saini* > > > -- Regards, *Gaurav Saini* |
Free forum by Nabble | Edit this page |