Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New GUI design #16

Open
tomek-szczesny opened this issue Apr 21, 2024 · 5 comments
Open

New GUI design #16

tomek-szczesny opened this issue Apr 21, 2024 · 5 comments

Comments

@tomek-szczesny
Copy link
Contributor

I read somewhere in PR discussions that perhaps one day we'd like to overhaul the GUI portion of Labelle.
I'm not too handy with programming but designing intuitive interfaces is something I learned quite well in the past.

If nobody opposes this idea then I could sketch a design with comments and remarks how things should look and work. I cannot promise any code though, I've never written a GUI in Python.

This is also a good place to write down any additional features that aren't present in Labelle GUI at the moment.

@tomers
Copy link
Contributor

tomers commented Apr 21, 2024

@tomek-szczesny that would be great!
At the moment, I think we should focus more on the component's hierarchy, i.e. which widget is grouped with which other widgets, and less on the styling details such as move something few pixel to any direction.
Today we work hard on supporting multiple devices, etc. In the future, we might shift towards label design.
Maybe you can get some inspiration here: https://youtube.com/watch?v=gaUUnGjAhvQ

Note that there could be two different approaches to design a label:

  1. Free-form - users move around and manipulate elements using the mouse (drag and drop).
  2. Hierarchial order - elements have a structure, i.e. a barcode, then a text label, then an image. The app resizes them automaticaly for the user.

Currently we support the 2nd method. We might support the other in the future. You should take this into account when designing the label editing UI.

@maresb
Copy link
Contributor

maresb commented Apr 21, 2024

Agreed that we're not quite ready for UI, but with that understood, some sketches may still be interesting.

I propose that we explicitly avoid taking any inspiration from that source with Labelle. I think we can do way better, and I really want to prevent any suggestions of impropriety.

@maresb
Copy link
Contributor

maresb commented Apr 21, 2024

Also, I'm not so convinced that we should put much more effort towards a native UI. I think a web UI would be way cooler. Like in an office setting, you could have a shared printer, and then anyone could open the web UI from any device or phone and print something out.

@tomek-szczesny
Copy link
Contributor Author

Thanks for your inputs.

I think that a well-thought GUI is very important, as the vast majority of Labelle users will prefer it over a command line.
I agree that copying any portion of Dymo software is a no-no and I believe we can do better than that. However the comments section contains some information on what to avoid in a good GUI.

My first job was designing test procedures in a factory, and GUI was a big part of it. I spent countless hours chatting with workers and listening to their comments. I like to bring up one example: Enlarging fonts in pop-up windows reduced average test duration by a few percent. Every detail matters, and every piece of feedback is important.
I made these GUIs in LabVIEW, a skill that is irrelevant to Labelle.

I'm not fond of web UIs but I accept the reasoning in favor. Ideally I'd keep both Python and Web GUIs, but that would probably mean twice as much work?

@tomers
Copy link
Contributor

tomers commented Apr 21, 2024

@tomek-szczesny, since we are using QT, you better try to play with QT Creator - https://www.qt.io/download. I am not familiar with that app, but you should be able to create some layout files which we can then mimic in our code. Loading this files dynamically is also supported BTW, but I guess we should not do it for now. This app should not require programming knowledge.

Regarding web UI, once we stabilize our code base, and we're far from that TMHO, then we can try to create an API. Once we have good API, we can create a basic web UI to use it, and create dockers for the backend and frontend (even a single docker for both will do).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants