On 7/24/20 1:55 PM, Ancor Gonzalez Sosa wrote:
On 7/22/20 4:53 PM, Ancor Gonzalez Sosa wrote:
The YaST team wants to take some time to think in the long term and try to envision the future of our UI design/programming... which may be anything from just an improved libYUI to something completely different and unrelated.
It likely makes sense to start discussing what are the requisites (and/or use cases) for the UI of YaST in the long term, so we have planned a meeting with all the interested people in this topic tomorrow Thursday at 2pm CEST. Usual meeting point: https://li2023-182.members.linode.com/#/rooms/2001
As said, the topic will be: requirements for the future UI of YaST.
Some food for thought about the topic:
- Do we ALWAYS need to offer TUI+GUI for all modules and steps? - Does it have any value to offer something else beyond TUI/GUI? - What are the requisites regarding support for programming languages?
Those are not the only points to discuss, just some hints to get your brain started.
# The Requirements Meeting: Results
1. Small glossary
- TUI: Text-based User Interface, what libYUI now provides through ncurses
- GUI: Graphical User Interface, what libYUI now provides through Qt
- WUI: Web-based User Interface accessible with a browser, what the Cockpit project provides
2. Meeting Context and Original Goal
The context of the meeting was: we are trying to envision how the future UI framework for YaST could be in the long term. That could be an evolution of libYUI, a replacement for libYUI or something completely different.
The scope/goal of the meeting was trying to define which would be the requisites for such hypothetical framework.
3. Minutes / Summary
3.1 Requisites from the User Point of View
As usual when we talk about YaST requisites in terms of what do we need to support, we got more questions than answers, since we don't have a formal and unified source of specifications and use-cases. Still, we opened interesting questions regarding TUI support:
- Do we need to offer TUI support for all operations and all installer steps?
- Are the UI needs (specially TUI) the same for the installer and for YaST as a configuration tool? If we make the separation of both more explicit, would that bring benefits in terms of fine-tuning the UI requirements?
- What is the least capable TUI terminal (emulator) we want/have to support? Is still ok to assume we have to support 80x24 without Unicode?
- Can we offer an alternative and more limited TUI for the more limited terminals? In linuxrc we have the linemode interface, which seems to be quite appreciated and used and which is kind of similar to what Red Hat does for the whole text-based installation process. https://en.opensuse.org/SDB:Linuxrc#p_linemode
- Idea: if we improve the usability and visibility of AutoYaST, it could become kind of a vehicle to reduce the options we offer during TUI installation. We could have a simplified interface that allows only for relatively basic installation and promote AutoYaST for the rest.
In my opinion, we should start focusing on answering every one of these points. We need to come with some use cases before moving forward.
We also discussed the idea of offering a WUI:
- We see real use-cases for it, like: * configuration via a web browser is kind of common/expected for embedded systems, IOT devices, etc. * sysadmins needing to adjust/monitor something when they only have a browser/tablet/phone at hand
- The cockpit project has attracted quite some attention, even in the (open)SUSE community, which seems to indicate there is a real interest from the users in having such UI.
Yes, IMHO, WUI would open quite some doors to YaST. But Web is quite different to desktop. I have doubts we can really extend the libyui concept for WUI.
As a last point regarding user requisites, It was also mentioned that YaST UI feels slow, going from one dialog/tab/section to another feels slow and inconvenient, and that's an operation that has to be done quite often.
3.2 Requisites from the Developer Point of View
It would be good if the new framework would allow fast prototyping, the minimum effort to create a prototype with the current tools is too high.
We should try to rely as much as possible in technologies/frameworks that are not invented and maintained fully in-house by the YaST Team. Knowledge silos are a very limiting factor.
Assuming we have several backends as TUI, GUI, WUI, etc. we don't want to be always limited by the less capable backend (80x24 TUI, in the current libYUI). We want to be able to take advantage of the particularities/tools of each backend.
One idea regarding the previous point: define widgets once and then get TUI + GUI + Whatever widgets that you can customize further: Abstract Factory -> Backend-specific Factory -> Backend-specific widget
Another idea in the same line: compared to libYU, it should be easier to redefine how some things work in a particular widget compared to its "base widget".
3.3 Other Topics
The meeting often drifted to other more or less related topics:
- Colaboration with manatools https://github.com/manatools/python-manatools
- The lack of separation of UI and "business logic" in YaST in general, which maybe is currently perceived by many YaST Team members as the most limiting factor to any UI-related discussion, beyond the UI framework itself.
Cheers.
-- José Iván López González YaST Team at SUSE LINUX GmbH IRC: jilopez -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org