Jump to: navigation, search

Ritmare interface: Use Cases

UC1-6: Interaction w. widgets

Use cases 1-6 describe the interaction of the user with widgets in the interface at box-level. This means that widgets are not considered for their specific functionalities but rather as interchangeable areas in the interface. In a nutshell, a given widget is associated one of the following states:

  • Foreground: That is, the widget is currently visualised in the main box of the interface;
  • Background: That is, the widget is currently visualised in some other visible box of the interface;
  • Icon: That is, the widget is temporarily hidden to the user and shown as an icon.

The idea is that each new widget in the Ritmare interface is immediately accessible to the user through a series of icons that are selectable in a specific area of the interface. This allows for a prompt notification to the user of new functionalities that are added to the infrastructure.

As a rule of thumb, it can be assumed that the interface has a main box where contents can be accommodated with the best ease. The other boxes can have different shapes and positions in the interface (say, a footer box as wide as the main one but shorter and two side boxes). Also, some widgets may have a static position that is not affected by the user's profile (e.g., the "login/user preferences" widget).

The number of boxes can be either static or dependent on the number of widgets that the user has selected. In both cases the sub-interfaces of the specific widgets shall be designed in order to be responsive, not only w.r.t. the specific device the user has (PC, tablet, smartphone) but also w.r.t. the organisation of boxes in the specific declination of the interface.

Uc1-6.png

UC1: Send widget to foreground

  • The user decides to focus on the functionalities of a specific widget while still keeping an eye on the other widgets hosted by the interface.
  • The user selects an appropriate button that is featured by all boxes in the interface.
  • The widget is now visualised in the main box.

UC2: Send widget to background

  • When a widget is sent to foreground, the widget that is currently in this status is sent to background. Different criteria are possible:
    • The widget sent to background is displayed in the box containing the widget that is sent to foreground:

PRO: The interface keeps a look and feel that is more consistent.

CON: The box containing the widget, when the latter is in background, is statically set (according to the user profile and the preferences she sets).

    • The boxes are given an order according to relevance and, when a widget is sent to foreground, the widget currently in foreground is sent to the box that is #2 according to the order.

PRO: More lively interface because, sooner or later, the distinct widgets may be hosted by all boxes in the interface.

CON: It is a different interaction criterion that shall be thoroughly tested for usability.

UC3: Maximise widget

  • The user selects a widget to be displayed full-size in the interface.
  • The user selects an appropriate button that is featured by all boxes in the interface.
  • The widget is now visualised full-screen.

UC4: Minimise widget

  • The user selects a widget to be minimised in the interface.
  • The user selects an appropriate button that is featured by all boxes in the interface.
  • The widget is now visualised in the box that has been hosting it before being maximised.

UC5: Include widget in interface

  • The user selects the icon corresponding to a widget that is currently not included in the interface.
  • The widget is assigned a box for visualisation.
  • The interface is redrawn accordingly.

UC6: Exclude widget from interface

  • If the number of boxes is fixed, when adding a new widget to the interface some other widget shall be excluded from the interface and rendered as an icon.
  • Otherwise, the user just decides that a given widget is not to be displayed in the interface other than as an icon.
  • The interface is redrawn accordingly.

UC7-13: "Login/user-preferences" widget

Use cases 7-13 start detailing the activities pertaining to a specific widget. Specifically, they deal with the management of user preferences, which essentially amounts to:

  • Handling the login/logout of the user to the porta.
  • Displaying and modifying some of the details on the user.
  • Displaying and modifying the widget selection that is related to her profile.

Uc7-13.png

UC7: Change authentication status

  • The user chooses to either authenticate to the portal or to log out from it.

UC8: Login to the portal

  • The user provides the login information which can be either a login-password pair or authentication information through a SSO mechanism.
  • The interface is redrawn according to the user profile.

UC9: Logout from the portal

  • The user decides to log out from the portal.
  • The user selects the appropriate "log out" button in the widget.
  • The interface is reset to the view made available to non-authenticated users.

UC10: Access user preferences

  • The user inspects the personal information that is stored by the infrastructure.

UC11: Change user details

  • The user decides to change the user details that are associated with her by selecting the "edit" button.
  • She is provided with a form-like interface by means of which information items can be changed. Some of these can be added/deleted.
  • When the user selects the "save" button, the updated information is sent to the backend.

UC12: Change widget selection

  • The user decides to alter the number and type of widgets that are associated with her account.
  • She is provided with a checkbox list by means of which she can add or remove widgets from the interface.
  • When the user selects the "save" button, the updated information is sent to the backend and the interface is redrawn according to the new widget selection.

UC13: Change widget positioning

  • The user decides to alter the relevance of widgets within the interface.
  • She is provided with the list of currently-selected widgets and, for each of them, the user can raise or lower the relevance of a widget.
  • When the user selects the "save" button, the updated information is sent to the backend and the interface is redrawn according to the new relevance information.

UC14-19: "Campaign manager" widget

The "Campaign manager" is the widget by means of which users can monitor the organisation of campaigns so that researchers can share the facilities that are required, the data that are collected, etc.

Uc14-19.png

UC14: Create new campaign proposal

  • The user inserts the details on a campaign she is going to carry out.

UC15: Delete campaign proposal

  • The user deletes a campaign she is not going to carry out anymore.

UC16: Create new campaign request

  • The user defines the parameters according to which the system may suggest her to join a campaign that is being planned.

UC17: Edit campaign details

  • This use case has a twofold purpose:
    • For the user that has created a campaign proposal in order to modify the details associated with the latter.
    • For the user that has created a cmapaign request in order to modify the parameters associated with her search.
  • The user specifies the parameters that are useful to ascertain the compatibility of proposals and requests, such as:
    • Geographic location of the campaign.
    • Start and end dates.
    • Measurements that will be carried out.
    • ...

UC18: Follow updates on campaign

  • The user is notified of updates, such as:
    • The insertion of a new campaign that may match the campaign requests associated with her.
    • A campaign that does not match anymore a request of hers because of updates in the campaign details.
    • The requests to join a campaign she has previously entered in the system.

UC19: Request to join a campaign

  • The user proposes herself to join a campaign.
Retrieved from "http://sp7.irea.cnr.it/wiki/index.php?title=Ritmare_interface:_Use_Cases&oldid=686"