@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

Reply via email to