GSoC Update and Phase One Feedback

[Alexander Bokovoy]

Hi Hezekiah,

On la, 04 heinä 2020, hezekiah maina via samba-technical wrote:
> Hi mentors,
> 
> I'm glad to have successfully completed phase one of the GSoC. I'm really
> grateful for the support and help you have provided during that time.
> 
> I wanted to give you feedback regarding the concerns raised in the just
> concluded phase one review and an update on building the packages for
> various distributions.
> 
> On writing a blog post on the work already done, I was thinking about
> writing it at the end of phase two as the project would be more mature than
> it's current state with some tests and build packages for the different
> distributions.
> 
> About my experience working with samba-tool, I hadn't had many problems
> working with it but to create a new user you have two options: create and
> add. There were some discussions on the mailing list about this and I think
> the verdict was to proceed with one and depreciate the other.

Yes, eventually one interface would be kept going forward. We keep
backward compatibility for quite some time for options, though. For
samaba-tool, I guess, making more consistent user interface would be
preferred but with Python it is relatively easy to keep compatibility
for 'older' interfaces.

> Another issue I encountered was using samba-tool dns in which you have to
> pass in your administrator password for the realm interactively on the
> console or as a flag. With other commands this was not a requirement and
> i'm not sure why it is required with dns management.

That might be a bug. Please file a bug at bugzilla.samba.org with examples
of an inconsistency and let's work together on fixing it. This would be
a good chance for your to submit a fix to Samba code base!

> Other than those two things the documentation for the sub-commands is
> wonderful and has really good examples.
> 
> I have decided to work with the Open Build Service, from the recommendation
> made by Alexander, to build the packages for various distributions. I was
> making the assumption that the most popular distributions used with Samba
> AD DC are RPM and Debian based. I'm seeking the community's feedback so as
> not to make the wrong assumptions on this.
> I created an account with the build.opensuse.org and have been exploring
> the UI and going through the documentation for OBS. I also created a
> Webhook in Gitlab to push the code to build.opensuse.org when there is a
> commit in the master branch. Is this the right way to do it or is there
> another option?

This sounds great -- we can start with RPMs as the spec file is already
there from the Cockpit starter kit and it works, so it should be
possible to instruct OBS to build RPM packages already. For Debian
packages, I'll look tomorrow for an example (Cockpit is available for
Debian, so we shouldn't have a problem to find an example for external
plugin package build).

> I also wanted to work on a better UI with some of the commands e.g showing
> the computer AD object. The current way for listing the results uses an
> alert group which isn't scrollable and can be a limitation when working
> with small screen sizes. I feel a better way to do it is to use a modal in
> which they appear on a list as they would on the console and make it
> scrollable if they don't fit on the current screen. There was also a
> suggestion from David on having to submit form input using the enter key
> and I will also work on it.

Looks like a good idea. May be file separate issues for these
improvements in the Gitlab's project and add your thoughts on UX/UI
changes as comments to each issue there. This way you can track the
thought process and allow others to comment on the proposals.

In Samba case we haven't been exposed to graphical design experience for
at least last decade or so. We had a graphical (Web) UI to configure
Samba in past but it was removed as nobody was really able to maintain
it and it was more or less 1:1 smb.conf options mapping rather than
something that follows use case needs.

In past few years David Mulder worked on the YaST UI for Samba AD DC
tools but I don't think that design work has left design decisions
artifacts -- I haven't looked in detail though. This is one part that I
find extremely useful to experience and knowing thinking of UX/UI
designers may change your views on usability too (I have been
collaborating on some aspects Nokia Maemo UX design during Nokia N900
and Nokia N9 times a decade ago when the whole UX for mobile was
relatively new and we had a lot of iterations and oscillations between
'too complex' and 'too dumb').

Having these ideas and research on UX improvements recorded as a part
GSoC work would be invaluable.

In Cockpit case, UI changes are typically discussed with design mockup
screenshots in the pull request or issue comments. We don't need to
follow those directly but I find useful some of their practices as they
allow to understand how decisions were made for UX/UI changes.

One of recent examples is this issue: https://github.com/cockpit-project/cockpit/issues/14196
More examples can be found here:
https://github.com/cockpit-project/cockpit/issues?q=is%3Aissue+is%3Aopen+label%3Aneedsdesign

-- 
/ Alexander Bokovoy