@Denis Noctor: I think you are right that we don't want to stop Maxim. I'm also not proposing to create Jiras for Maxim to fix. I propose to create Jiras to fix them myself. And already did submit a few PRs based on some of my suggestions: https://github.com/apache/openmeetings/pull/63#issue-405378990 and https://github.com/apache/openmeetings/pull/59/files/89a006c507371c658bf5cc938a4bdef69b609513#r407924797 => But the consensus based on discussing with Maxim+Denis was that we should discuss those on the mailing list first. Because some of the UI elements have been changed back n forth even since I can remember 5+ years ago. And he is prob right that getting more feedback is better then less. => So I'm asking for more feedback on proposals - So we can agree on UI/UX changes - I can do the code fixes - on top of what Maxim does. And also the PR doesn't need 100 comments cause we agree on the design before doing the change.
@Peter yeah some mobile design would be nice. I have not had time to mock anything up yet Cheers Seb On Sun, 19 Apr 2020 at 20:11, Peter Dähn <da...@vcrp.de> wrote: > Hi all, > > I think this is a good time to have a look at mobile view of OM. Maxim > changed everthing (?) to bootstrap so we have the precondition to have a > look at it. > > Greetings Peter > > Am 19.04.20 um 09:12 schrieb Maxim Solodovnik: > > Hello Sebastian, > > > > I believe above rules should be tweaked > > For example: Right now "Request right ***" icons/menu items are hidden > > in case user already have particular right > > It seems to me this behavior doesn't fit the rules you are proposing > > > >>> all whiteboard tools including the document navigation should be > disabled if there is currently nothing to select > > So you are proposing to show page navigation even if there is no > document on WB? > > > > > > p.s. I found no inline comments in confluence :((( > > > > On Sun, 19 Apr 2020 at 13:59, Maxim Solodovnik <solomax...@gmail.com> > wrote: > >> The VOTE for M4 has been started: > https://markmail.org/message/zuduhgvci7lm2owy > >> > >> On Sun, 19 Apr 2020 at 13:56, <i...@bureau-de-poste.net> wrote: > >>> Hello, > >>> > >>> Let's NOT let this style guide idea block the forthcoming 5.0.0 > release - which we have been waiting for for so long, please. If people > want to have a style guide - let's do it for the 5.0.1 or 5.1 release, > please. This will take too long to do before the 5.0.0 release. > >>> > >>> best, > >>> > >>> Ed > >>> > >>> > >>> Quoting seba.wag...@gmail.com: > >>> > >>> Hi, > >>> > >>> I would like to establish a Style Guide for OpenMeetings. > >>> > >>> Why is it important to have a Style Guide > >>> A Style guide helps to make consistent design decisions. A reference > to agree on before doing try-and-error discussions that can be costly and > frustrating. In the end it may not really matter if the colour of the alert > modal is red or orange. And it may not matter if the OK and Cancel button > is left and right. Or the opposite. > >>> > >>> But what matters is that once you decide for one of those patterns you > do it consistently! Not come up with alternating patterns or have various > different versions of a UI/UX of similar functionality. > >>> > >>> Further material and examples on what a typical Style Guide (and > StoryBooks) would contain and solve: > >>> > >>> https://www.toptal.com/designers/ui/ui-styleguide-better-ux > >>> http://styleguides.io/examples.html > >>> > >>> So I made a start here: > >>> > https://cwiki.apache.org/confluence/display/OPENMEETINGS/OpenMeetings+UI+and+UX+Style+Guide > >>> > >>> And I started with 2 topics: > >>> > >>> Hiding vs Disabling of elements: > https://cwiki.apache.org/confluence/display/OPENMEETINGS/OpenMeetings+UI+and+UX+Style+Guide#OpenMeetingsUIandUXStyleGuide-HidingvsDisablingelements > >>> Primary vs Secondary call to actions buttons: > https://cwiki.apache.org/confluence/display/OPENMEETINGS/OpenMeetings+UI+and+UX+Style+Guide#OpenMeetingsUIandUXStyleGuide-PrimaryvsSecondarycalltoactionsbuttons > >>> > >>> Needs your Support > >>> If you could please add some feedback on those topics. > >>> And also if you could help adding more topics where you feel like > there is some inconsistency that would be worth agreeing on. > >>> > >>> I appreciate this could be a long process and seems tedious to discuss > this in such detail. But it will be much faster to discuss this in theory > and agree (or disagree) on a style guide than refactor things later. > >>> As well as it will help to discover inconsistencies that make the > application hard to use. > >>> > >>> Thanks, > >>> Seb > >>> -- > >>> Sebastian Wagner > >>> https://twitter.com/#!/dead_lock > >>> seba.wag...@gmail.com > >>> > >>> > >>> > >> > >> -- > >> Best regards, > >> Maxim > > > > > > -- Sebastian Wagner https://twitter.com/#!/dead_lock seba.wag...@gmail.com