breaking_the_yast_users_ui.md

Main dialog

• Less tabs: The module is intended to manage users and groups. So, let's keep the dialog simple using just two tabs: Users and Groups
• More information at first glance: Tables could include more columns (i.e, "Default group", "Administrator", "Type", "Additional Groups", "Blocked", etc)
  • Advantages: there are more sorting criteria at hand
  • Disadvantages: probably too much, too crowd; horizontal scroll may appear 😕
• Better filter explanation
• Use a filter popup instead a dropdown: allows grouping filters and, eventually, adding some simple and small inline help when needed, more straightforward than moving explanations to the "Help" button
• Use the top menu bar: TODO: write the reasoning, pros and cons

User form

• Unify tabs: looks like there are too many tabs... or at least the information is not grouped as well as it could be. However, is not an easy task. Below some of my attempts (I'm not happy with any of them, but upload the screenshots worth it)

  • All together

    It does not need more explanation, the screenshot talks by itself.

    

  • Using only two tabs

    Basic tab looks ugly and advanced does not fit in 80x24

    UI type	Basic (the most common used fields)	Advanced (the less common things)
    GUI
    TUI		Note that this distribution does not fit in 80x24: few lines automatically lost

---

A re-reminder: Do not try to create grids / columns using HWeight: texts will be cut. See below

Instead, use MinWidth(HSquash(number, widget)) to emulate a MaxWidth, although is far to be perfect for emulating grids since still being a MinWidth:

---

Other notes:

• Inline labels: as i18n, we don't know the exact or even the max width

A re-reminder: Do not try to create grids / columns using HWeight: texts will be cut

Using the @jreidinger's approach seems that does not make a big improvement to that regard, since we don't know the long of a label for every translation (and there is not auto wrapping at widget level)

def main_content
      HBox(
        HStretch(),
        VBox(
          Left(Heading("LEFT COLUMN")),
          VSpacing(2),
          CheckBox("An option with a very long label to see what happens with the 'grid'"),
          VStretch(),
        ),
        HStretch(),
        VBox(
          Left(Heading("RIGHT COLUMN")),
          VSpacing(2),
          CheckBox("Another option here"),
          Left("Using a shorter text this time"),
          VStretch(),
        ),
        HStretch()
      )
end

Thanks David for your mockups, great work. I would like to add some comments.

I like the idea of the main dialog. And regarding the menu bar, I vote for adding it because a menu bar would simplify the UI a lot. Also note that this module is only executed in a running system, where the menu bar is kind of natural. In the Expert Partitioner for example, we have the menu bar even in the installer. In the yast-users case the menu bar would no be that breaker as in the Partitioner.

And for the user form, I would tend to something similar to your first proposal (with buttons to open popups for extra settings for home, etc) instead of a version with tabs. IMHO, having the buttons right there would make easier to find the extra settings for specific aspects like the home directory or the password. With a separate tab, the context of the extra settings is kind of lost, and it would more difficult to understand.

Thanks Iván.

I agree with your comment too. Please, keep in mind that this gist is only a rough draft of some of the ideas which I have been playing, but not all combinations that I have planned. More precisely, the ideas I already tested with some real code to produce the UI.

But, as said, I'm not happy with them since the results looks too crowded even in the approach I like the most, the one you said in the last paragraph: minimal fields with the [More...] buttons for opening a popup with more advanced configuration, which should be already filled with reasonable defaults.

Using the @jreidinger's approach seems that does not make a big improvement to that regard, since we don't know the long of a label for every translation (and there is not auto wrapping at widget level) -- (see comment above)

There are other issues when trying to achieve a grid based form like the one displayed below, namely

• The complexity for building it

  Click to show/hide some Ruby code

  HBox(
          VBox(
            grid_input(InputField("Name")),
            VSpacing(1),
            grid_input(InputField("Username")),
            VSpacing(1),
            grid_input(InputField("Password")),
            VSpacing(1),
            VStretch()
          ),
          HStretch(),
          VBox(
            grid_input(InputField("Surname")),
            VSpacing(1),
            grid_input(InputField("Home Directory")),
            VSpacing(1),
            grid_input(InputField("Password Confirmation")),
            VStretch()
          ),
          HStretch(),
          VBox(
            VSpacing(1),
            VSpacing(1),
            VSpacing(1),
            PushButton("More..."),
            VSpacing(1),
            VSpacing(1),
            VSpacing(1),
            PushButton("More..."),
            VStretch()
          ),
          HStretch(),
        )

• The tab index goes from top to bottom instead from left to right.

Good news is that I believe I found a way to do it with less complexity and keeping the tab movement through rows

   # NOTE: this is draft code; don't kill me... yet.

   def row(*inputs)
      fields = inputs.flat_map do |input|
      field = if input.is_a?(PushButtonField) 
                  grid_input_without_label(input)
                else
                  grid_input(input)
                end
        [field, HSpacing(1)]
      end
    
      Left(HBox(*fields.tap(&:pop)))
    end

    def grid_input(input)
      HSquash(MinWidth(21, input))
    end
    
    def grid_input_without_label(input)
      VBox(
        VSpacing(1),
        input 
      )
    end

    def main_content
      Top(
        VBox(
          Left(Heading("Creating/Editing a user")),
          VSpacing(0.5),

          row(InputField.new("Name"), InputField.new("Surname")),
          VSpacing(1),
          row(InputField.new("Username"), InputField.new("Home Directory"), PushButtonField.new("More...")),
          VSpacing(1),
          row(InputField.new("Password"), InputField.new("Password Confirmation"), PushButtonField.new("More..."))
        )
      )
  end

And for the user form, I would tend to something similar to your first proposal (with buttons to open popups for extra settings for home, etc) instead of a version with tabs.

A drawback of this approach is that it could make a bit difficult the task of editing. I mean, when editing a user you are not going to see all related data at first sight. This looks ok when creating a user, but not sure if is the right way when editing.