Design and Development discussion

I had today a discussion with some students about the design and development of a simple application. My demo application consists of one window with:

  • A DesktopToolbar with close, add, edit and delete buttons;
  • A DesktopListbox used to display data from a database table. The listbox can easily be bound to another table;
  • A DesktopContainer used for viewing, adding, editing and deleting data. Depending on the data in the database table the container consists of DesktopTextfields, DesktopComboBoxes etc.The container also contains a Cancel and Save button. Depending on the database table the DesktopContainer will be replaced by another DesktopContainer.

My Questions:

  • Does my design meets modern UI design rules?
  • Is it advisable to put the Toolbar and the Listbox in a separate container?
  • Is it advisable to put the Cancel and Save buttons in a separate container?

Layout, it is ok, the rest, not really. If you are not going with the OS theme, look for a good palette, instead of just use random colors, that black is really hard on the eyes.

No

Container only make sense when you are going to reuse the UI, if you are going to have a single instance of it, actually does not make sense to have any container.

To play Devil’s advocate here, that is not necessarily true. I’ve been known to use Container controls only where there is a single instance of it for a variety of potential reasons:

  • Single object to enable / disable
  • Single object to make visible or not
  • Allows “lock to” edges to be based on container instead of window
  • In some cases easier to edit in IDE
  • In some cases easier to reuse in other projects
  • Etc
3 Likes

I have single-instance Containers on such as PagePanel pages. Sometimes controls were behaving strangley, so I just moced everything off the Page panel page and into a Container, then put an instance of that on the page instead.

1 Like

Thank you all for your comments.

  • Design: @Ivan_Tellez True, the black color is hard on the eyes. The main comment of one of the students was that the use of a Toolbar is ‘outdated’/‘old-fashioned’. I didn’t agree with that comment.

  • Cancel/Save in separate container: The remark made by the students: a Cancel/Save buttons container could be reused on all containers that use this framework. This remark is true. So, I doubt myself whether the use of a container would be a more optimal or better solution or even to put the Cancel/Save buttons in the Toolbar.

Did any of the students suggest asking the users, or doing any UI testing with users? Have they read Tog on Interface? An old book, to be sure, but still relevant. Personally I’d fail anyone who considered ‘outdated/old-fashioned’ to be considerations of any importance.

1 Like

@TimStreater Master students usually have their own opinions about design and programming style. I use xojo to illustrate UI design and to demonstrate the usefulness of using certain controls in programming (in this example DesktopContainer). And yes, they like to discuss but above all they prefer to pass the exam at the end of the academic year.

@Jean-Yves_Pochez I will discuss the use of modal windows next week. I note that you have a OK button in the toolbar. Is this button used to save edited data (Save button in my design)?

yes OK is for “Save” , but in french it is “Enregistrer” and it is quite long so I use only “OK” to save.
“annuler” is cancel

all the windows are modeless. you can work in any window at any time
there is a palette window with all the available tables (for the logged user)
if you clic on a button on the palette you get the list of records for that table
then an “edit” command or double-clic brings the editing window for the selected record.

@Jean-Yves_Pochez What was your reasoning for putting the OK button (Save) in the Toolbar and not at the bottom of the editing area (e.g. a separate OK button below the Artist Textfield)?

mainly for it to be always at the same place on the window, no need to search for it with eventual scrolling ?
and to have all the commands previous next record, ok cancel at the same place.
I don’t see any problem at putting it at the bottom of the editing area.

Thanks to everyone for all comments and suggestions!

It does look old-fashioned, in my opinion. The main reason I suspect behind that critique is not that the toolbar is old-fashioned per se, but the icons make it look so: the combination of grey background and heavy, full-colour icons immediately gives the “1999” vibes.
Opting for monochromatic, theme-savvy line icons would be a much more modern way of doing it. There are many websites with free great-looking icons: lucide.dev and iconic.app are two websites I use.

Toolbars are still a common way to access commands and for good reasons. Just open the Photos app on your Android phone and you’ll find a toolbar at the bottom of the screen. Their existence needs to be justified though, perhaps there are other ways of presenting commands that are more appropriate.

2 Likes

There’s also too few functions in the toolbar to justify the amount of unusable space on the window. Having so much window chrome within the window’s real estate makes it look outdated and poorly designed. Use smaller icons, at least. Text to the right of those icons to reduce height and the amount of wasted horizontal and vertical space. Or just use menus. This is one reason you see toolbar-type icons occupy the same space as the window management buttons and title these days.

ui should look consistent.
for actions your should have to know its context.
i like to have a context menu at the list itself.
important are short ways with mouse.
ui must be understandable and intuitive.
color scheme should be optional.
in single window you can not copy/paste/compare from one to other view.
i like to have the tool bar near to the last click, as example save.
some people like the toolbar at a lower position, others maybe on the left.

@Andrea_Suraci Great suggestion! I didn’t know these websites. And, yes these icons look more modern.

1 Like

@Anthony_G_Cyphers I agree: the Toolbar takes a lot of space in the Window. Of course, I can use smaller icons. Is it possible in XOJO to put text to the right of an icon?

I used traditional menus before. The use of a Toolbar in this example was intended to illustrate another way of using menus in an application. I have the impression that younger people may prefer traditional menus. This surprises me a bit: students are used to clicking icons on smartphones and tablets.

Not out of the box with the standard Xojo toolbar. It’s very limited. I tend to roll my own for a completely custom appearance and functionality or use GraffitiRibbon. It’s fairly common, in my experience, for other professional software built in Xojo that needs a toolbar to also use custom drawn toolbars built on Canvas. There are drawbacks to doing it this way, but you get complete control over the appearance of the toolbar. I believe MBS also has toolbar customization functions, but I have no experience with those.

@MarkusR The colours are indeed very exaggerated: but it is looks great when you beam this window on a large projection screen. I also tried to elicit reactions from the students on the colours used.

You gave me a good idea by suggesting contextual menus. Indeed, you save a lot of space by eliminating the Toolbar and context menus are available where the action is (e.g. on the Listbox). Until now I didn’t cover contextual menus in my lessons.

Is it possible in XOJO to position a Toolbar left, right, or bottom in a Window? I think Toolbars are always on top of the Window. But maybe I’m wrong.