Tails

#1 Updated by segfault 2016-04-06 14:43:52

I pushed an initial design of the GUI here:
https://gitlab.com/segfault_/tails_server.git

I designed it with Glade. You can open the .glade file with Glade or execute the .py file to run the GUI. I also append a screenshot.

At the moment the icons will only be visible if you have the respective application installed (i.e. mumble, gobby-0.5 and owncloud-client). I did not implement the settings dialog yet, which should contain application specific settings, e.g. for the mumble-server it would contain the option to set a SuperUser password and the server’s welcome text. Clicking the question marks on the right would open the documentation, which is not written yet :)

Please provide feedback!

#3 Updated by anonym 2016-04-08 04:25:12

I think the current prototype looks absolutely fabulous! :)

segfault wrote:
> I designed it with Glade.

Just a thought: I’m pretty ignorant of Glade, but my understanding is that it’s useful for statically defined user interfaces (e.g. those drawn in Glade’s editor), whereas at least the design I proposed before is highly dynamic, i.e. the GUI is generated from some external non-Glade description. Can you make something like “templates” with Glade that then can be instantiated by each service programmatically? If so, that would still be useful.

Any way, Glade is clearly excellent for making a demo GUI (especially with the editor), which perhaps was the reason for using it at this stage. :)

> I did not implement the settings dialog yet […]

And not the “connection information” (generated passwords, URI:s etc) either. There would be some overlap there with the “Address” label + text box. Probably it doesn’t have to be duplicated, but made into an obligatory part of the “connection information”.

Here’s an idea: what about killing the “Settings” button, and instead have all connection info and all options/settings shown in the frame exposed by clicking the “More” expander; and when a service’s section is expanded all other services’ entries are hidden. That way the GUI morphs between the requested states instead of requiring a new window, which I guess is better UX according to current doctrine.

> e.g. for the mumble-server it would contain the option to set […] the server’s welcome text.

Note that I only presented that option as an example. I truly do not care about supporting it as a user option. :)

#5 Updated by segfault 2016-04-09 02:20:18

anonym wrote:
> Just a thought: I’m pretty ignorant of Glade, but my understanding is that it’s useful for statically defined user interfaces (e.g. those drawn in Glade’s editor), whereas at least the design I proposed before is highly dynamic, i.e. the GUI is generated from some external non-Glade description. Can you make something like “templates” with Glade that then can be instantiated by each service programmatically? If so, that would still be useful.
I’m new to Glade but as I understood it, it just creates GTK objects that can be modified programmatically. So I think I will be able to instantiate them dynamically.

> And not the “connection information” (generated passwords, URI:s etc) either. There would be some overlap there with the “Address” label + text box. Probably it doesn’t have to be duplicated, but made into an obligatory part of the “connection information”.

Right, I didn’t do this one yet. Maybe we should just create a single text box “Connection Information”.

> Here’s an idea: what about killing the “Settings” button, and instead have all connection info and all options/settings shown in the frame exposed by clicking the “More” expander; and when a service’s section is expanded all other services’ entries are hidden. That way the GUI morphs between the requested states instead of requiring a new window, which I guess is better UX according to current doctrine.
Yes, I like that idea. The idea of Spencer goes in the same direction.

SpencerOne wrote:
>The bits could use some rearranging so as to more suitably group respective elements.
>tails.server.gui.alt.png has some options [attached] that reflect such arrangements.
Nice! I like the idea to use a single settings frame for all services. It also solves the space problem we would have with my design once we have many services. I think design three looks even nicer than design two. Did you use Glade for these? If so, could you provide the .glade files?

#6 Updated by anonym 2016-04-12 01:38:52

Indeed, Spencer’s designs two and three are definitely improvements vs space and, IMHO, clarity. I also like the list’s “+/-” buttons — I assume here that they are used to activate/deactivate services (among the templates we provide) as opposed to start/stop them. In my original vision I thought these concepts could be conflated some how, but I am getting less sure that can be done in a conceptually sound way.

The difference between designs two and three, namely the “Close” button, made me think about how user-settings will be applied. The implicit assumption here seems to be that they are applied immediately after modifying via the GUI controls (GNOME style). Since not all services support reloading their configuration while running, the service may need to be restarted, which could surprise users. Therefore it might be worth considering treating user-setting differently, e.g. as soon as they are modified we instead add an “Apply and restart” button. Thoughts?

Another thought: it might make sense to only show the “Persistent” option when adding a service (i.e. in whatever sort of dialog that is shown when pressing “+”). I say this because I expect it to get really complex to allow to toggle this one after start, since it may involve copying the service’s configuration, restarting and probably more design decisions that we likely want to just not have to think about.

#7 Updated by intrigeri 2016-04-13 17:27:23

In passing, it would be super nice if you could use ticket titles that are a bit less generic than “Design the GUI” :)
Thanks for working on this topic!

#9 Updated by segfault 2016-04-20 09:42:31

> In passing, it would be super nice if you could use ticket titles that are a bit less generic than “Design the GUI” :)
Sure, sorry about that.