In general, the goal is to have the students make a simple desktop app in Swing. The following illustrations are meant to serve as a guideline to structure. The visual style of the students’ application itself is not in question, although the author believes that positive inspiration in the form of a modern design may help them imagine what their creations could possibly look like.

Inspiration can be found for example in Windows official guidelines. The following illustrations were made using Figma, but they are not perfect because Figma is a mysterious tool. The file can be accessed here.

Application frame and content container

The base of the application should be a tabbed application as follows: Tabbed pane Notice namely

  • app title
    • upper left corner should contain the name of the application
  • upper file menu
    • if applicable, file menu is a typical desktop application component
  • tabbed pane
    • each tab should contain different content, e.g., list of currencies, transactions…
  • quick actions menu
    • text or icon buttons with the most used/important functionality
    • the quick actions menu as it is illustrated in this picture is only applicable to data in the current tab
  • content pane should contain table with data
    • above it, there can be filters or search bars
  • scroll bar
    • in case the data is too big, the table should either accommodate it, or it should be scrollable so the user can see all the data and nothing is cropped

Tabbed_pane_menu_open Upon clicking, the file menu buttons should simply list the sub-options.

Tabbed_pane_quick_actions_global The quick actions menu can be also above the tabbed pane, to provide shortcuts for the most used actions.

  • the position of the quick actions menu should be determined by the need for it - a.k.a. the use case

Visual feedback

  • tooltips
    • every good application needs sensible tooltips - web or desktop one
    • every button should have a tool tip
  • right click context menu
    • in desktop applications, it is normal to have a right click context menu available
    • if applicable, record specific actions such as edit or delete should be possible to be performed via such menu
  • separator (in the menus)
    • if applicable, in case file menu or right click context menu is used, the groups of actions should be visually separated by a separator
  • progress bar
    • if applicable, the user should be informed about progress status via progress bar
      • it could be information about retrieval data from a database (but this would be very quick)
      • it could be information about budget spending for the month, etc.
  • status bar
    • if applicable, the user should be informed about the current status according to the context
      • e.g., connection status, summary statistics about items (filtered/total number of table rows, etc.)
      • it could be summary (filtered vs. total) statistics of the most important metrics of the items

Other UX

  • the windows guidelines dictate minimum frame and dialog sizes
    • we want to make students conscious about their design decisions, and setting simple attributes like minimum frame size according to the guidelines so the app has no trouble running on various screen sizes can help that
    • recommended window size = good starting point to start writing the app = 1920x1080
    • minimum window size = smallest size required by Windows: 320x320
      • if that is impossible to meet, then at least width 500 is required for the app to be compatible across common screen sizes

Dialog

Below, there is an illustration of what an input dialog could look like. Input element types are described further below.

Dialog

Important notes

  • the last open dialog must be on top of all other elements
  • the last open dialog must be the only interactive element = it cannot be possible to click out of/behind the dialog
  • the dialogs can stack on top of each other
    • if addition of one entity (e.g. item) requires addition of another one first (typically a category), the “add category” dialog must be accessible from the “add item” dialog and after adding the category it must be possible to continue in adding the item
  • when there is an error in the input, the dialog should stay open, display a meaningful error message and indicate what is wrong and let user correct the mistake
  • as majority of users in our demographics use MS Windows, we use windows style buttons
    • save on the left, cancel on the right

Input

According to the data which needs to be filled in, the students should use the most suitable element, not just text fields everywhere. The justification for this is simple - minimize mistakes made by users and make the application intuitive to use.

The data should also be properly validated. Required fields should be marked accordingly (e.g., red star) and meaningful error messages should be provided to the user.

Components:

  • slider
  • combo box
  • dropdown list
  • radio button
  • checkbox
  • text field
  • date picker
    • the students should be able to find a suitable library for proper date management, especially if the app is date/time-sensitive, e.g., regarding finances
  • time picker
    • the same applies for time picker, although the spinner component could be satisfactory

Icons

Again, there are several UI guidelines the students may find appealing. For Windows apps/Fluent UI the following guidelines apply: LINK

However, java seems to be scarce in terms of built-in icons. There are some default icons, but they are fairly ugly (can be found here).

Example: image There are Fluent UI packages available, but the icons might need to be converted from .svg, e.g., here.

Overall, the goal is to be consistent in design.