On Mon, 14 May 2018, 20:38 Taher Alkhateeb, <slidingfilame...@gmail.com> wrote:
> Hello Scott, thank you for your thoughts, inline ... > > On Mon, May 14, 2018 at 10:45 AM, Scott Gray > <scott.g...@hotwaxsystems.com> wrote: > > I think no matter what we use someone will always want something > different. > > I'm beginning to lose count of the number of custom APIs I've written > over > > the years to support custom UIs. > > > > I think the bigger win would be to start providing APIs and rewriting our > > existing screens to use them. From there we could start looking at new UI > > frameworks. > > Do you mean by APIs rewriting our XSD files and model objects? Why > rewrite? Why not just enhance them for new / missing functionality? > What are the flaws you'd like to redesign? > No, I'm talking about web services. With well designed web services custom projects would be able to build out new user interfaces in a lot less time and we'd be able to poc new interfaces for the community project without even touching the existing codebase. > > > > > Most of the projects I've worked on have needed huge amounts of UI > > customization and having prebuilt APIs would have reduced the workload > much > > more than having a shinier UI that still needs to be completely > rewritten, > > although I'll admit the latter would probably help the sales process. > > The "shiny" part is a plus, but not the core of my suggestion. The > reasons I suggested these libraries are: > - bootstrap: the grid system, this is the cake for me. You have a > powerful responsive grid system for better layouts. The buttons, > tables and other bling bling are icing on the cake. > - Vue: The core of this technology is to allow binding of your context > model to the DOM so that you don't write oodles of JavaScript and > Jquery to create dynamic behavior. It's really old school in 2018 to > keep jumping between many pages to get something done. > > > > > Does it not worry anyone else that our service engine still only defines > a > > basic map for in/out parameters when the rest of the world is using the > > likes of swagger and restful APIs? > > Of course it worries me, and if you start an initiative I will be the > first to jump in and volunteer. In fact it's on my todo list, and I > was looking at multiple options lately and I'm very attracted to > GraphQL for example because of the reduced visits to the backend. > However, I don't see this as being related to my proposal here, I'm > just setting my own priorities of what to work on next. What's wrong > with starting _both_ initiatives for that matter? > Nothing is wrong with both, but as you pointed out many discussions and efforts have begun and then floundered. I'm simply offering some thoughts on where I see the most potential benefit from a large scale effort. > > > > > Regards > > Scott > > > > On Sun, 13 May 2018, 06:03 Taher Alkhateeb, <slidingfilame...@gmail.com> > > wrote: > > > >> Hello Everyone, > >> > >> Recently, we at Pythys had some interactions with clients, and the > >> user interface proved to be a sour point. It is functioning well, but > >> looks too classic, too rigid, too 2000s really :) We had many > >> discussion and attempts in the past like [1] [2] [3] [4] [5] [6] [7] > >> [8] [9] [10] just to name a few all of which seemed not to follow > >> through. > >> > >> So what is the problem? Why is this hard to get right? I'm not sure I > >> have the magic answer, but it seems to me like part of the problem is > >> simply .. TOO BIG > >> > >> So I was thinking about a possible solution, and after some initial > >> research, I think maybe the solution (like everything else) needs to > >> be slow, incremental and evolutionary rather than revolutionary. So I > >> am suggesting the following ideas to try and move forward: > >> > >> - We include the assets for Bootstrap in the common theme. Bootstrap > >> will give us the Grid system which allows for a responsive website > >> that works on all devices, it will also give us beautiful widgets to > >> work with. > >> - We include Vue.js assets in the common theme. Vue.js is an excellent > >> framework for creating Single Page Applications (SPAs) to give dynamic > >> behavior to our pages and create ajax-heavy pages > >> - We slowly migrate our old CSS to bootstrap constructs. We can begin > >> for example by replacing our menus, then tables, then headers, then > >> buttons etc .. > >> - We slowly introduce dynamic screens using controller logic in Vue.js > >> - We slowly update our macro library to migrate to the above mentioned > >> libraries and widgets > >> - We do all of this live in Trunk, without branching. This means that > >> for some period of time, there will be transitional code (a little bit > >> of bootstrap and a little bit of our current code) > >> > >> We can start with an initial proof of concept skeleton, and if that > >> gets consensus, then we can move forward with a full implementation in > >> trunk. I think this issue is many years over due. Our interface looks > >> oooooooooooooold and really needs a face lift. > >> > >> What do you think? Ideas? Suggestions? > >> > >> [1] https://s.apache.org/rf94 > >> [2] https://s.apache.org/g5zr > >> [3] https://s.apache.org/XpBO > >> [4] https://s.apache.org/YIL1 > >> [5] https://s.apache.org/836D > >> [6] https://s.apache.org/DhyB > >> [7] https://s.apache.org/Lv9E > >> [8] https://s.apache.org/zKIo > >> [9] https://s.apache.org/D6jx > >> [10] https://issues.apache.org/jira/browse/OFBIZ-5840 > >> >
