HackMD - Collaborative Markdown Knowledge Base

### Functional Requirements #### General 1. *ADEv2* is compatible with desktops, laptops, tablets and mobile phones. #### Login 1. The Login screen accurately informs users when there is something wrong with their provided account details. (Quality Of Error Messages) 2. Users can select to remain logged in on one machine until their password is updated or they explicitly log out. (Adaptibility) #### View courses 1. Users are able to view 5 workdays for a range of at least a block (~3 hours) at once. 2. Users only see their own courses. 3. Only course names and rooms must be displayed when looking at a week schedule. (Information Density) 4. Only the week which is requested should be shown (Explicit User Action) 5. Users should be able to control the information available and visual style of the view (Flexibility) 6. The view should be controllable with keybindings (User Experience) 7. Different types of entries (Lectures, Seminars, Practicals) should have different but consistent symbols or signs (Significance of Codes & Consistency) 8. Visual Configuration should be possible in 2 areas: colors, available information. These two should be clearly distinguished (Grouping/Distinction of Items) 9. Configurations should be saveable (Flexibility) 10. Configuration should be possible in Color selectors, HEX codes and CSS (User Experience) #### Export 1. Users should be able to print any day, week or month schedule (Compability or Flexibility IDK) 2. Users should be able to export to CalDav (Flexibility) #### Logout 1. Users should be prompted before logging out before saving a configuration (Error Protection) ### Task Tree ![](https://i.imgur.com/okYq0ow.png) The task tree describes the scenarios from the *Requirements Documents* and describes every step required by the user to achieve the scenario's result. Some steps are mandatory to continue (e.g., opening ADE and login) and some finish the user session (e.g., closing ADE). The task tree puts steps in a sequential order by using the *then* keyword. The task tree contains optional steps (e.g., view course, export and logout). Those steps are written with the *O* label. There are also steps who can exist in parallel. An example is selecting and viewing courses which can be done simultaneously. The task tree utilizes the *//* symbol for concurrent behaviour. ### Methodology   Functional Requirements summarize the answers in interviews of the ERD document and (the connection to) the Ergonomic Criteria. These also describe a hierarchy of importance in required functionality. These functionalities are consequently put into the task tree. The scenarios and tasks then help to reason about the main design decisions. To summarize and expand, interviewee answers, existing products (e.g., similar applications and previous iterations of ADE) and the functional requirements define the design goals. These goals have a direct impact on the abstract UI-views. In the end, analysis of the design choices detail the specifications and the relation to the Ergonomic Criteria. ### Main design decisions   The main design decisions consider both the functional requirements (micro-decisions) and the design goals (macro-decisions). A previous section describes the functional requirements. The design goals are *readability*, *simplicity* and *low latency*, which all stem from the usage contexts given in interviewee answers. Readability refers to the large, diverse audience. Simplicity refers to the compatibility requirements. Low latency refers to the speed and complexity requirements. Ergonomic Criteria provide a framework to balance the design goals and functional requirements. Within the design, the recurrence and urgency of a task decide the number of actions required by a user to perform that task. The minimal number of actions necessary to view the current day's or week's schedule versus the number of actions required to export a semester's schedule illustrates this decision. This refers most to both simplicity and low latency. Furthermore, the readability on mobile and tablet devices [General 1] improves when the content covers more screen space. Therefore, the data view provides a larger view of the content at the cost of some actions for less common tasks. The product consists of 2 base views which can improve simplicity. Namely, these views are the login and data view. Derivatives of the data view perform other tasks which provides context during these tasks. For the user with less restrictive complexity requirements focus also falls on configuration [View Courses 5, 9, 10]. #### a. For getting the right design   The login view is simple and standard. It invokes no surprises and matches the pragmatic nature and design goals of the product. One improvement which stems from functionality requirement [Login 2] is the extra options. The data view has a few variants. The main view reserves as much screen-space as possible for the content. The content concerns the week's courses. Buttons are accessible but out of the way and more brief than their earlier counterparts. Many uncommon actions, which previously took up main view screen space, move to the top menu bar as to provide both concision, grouping and consistency. Note that power-users can adjust both colors and text-sizes to better serve them. #### b. For getting the design right   To go into some of the more specifics of the data view, there are some variants. The prompt, which triggers when logging out without saving a created configuration, provides a clear alert to the user that an (important) decision is to be made. Within the course view, both the course information and its context are visible (except within the mobile view). This aims for more compatibility with the task characteristics which are most executed. The exporting view shows only two buttons, which create a clear expectation from the user. ### External specifications #### a. Descriptions   What follows is a description of the task tree. The first thing the user does is connect to the system. When they open *ADEv2,* they are prompted with a login screen. This login step is required before any other action may be taken, (note the use of the keyword *then* in the task tree). The screen presented to the user at any given time varies depending on whether they are using mobile, desktop or tablet. (See the models of our adaptable abstract-UI). The login page is simple and intuitive. It does not vary much depending on the device being used. Once a successful login has occurred, the user is presented with the data view of *ADEv2*. Our models depict the variations between devices – notably a simpler UI for mobile in order to be compatible with the reduced space available. In this state, according to the task tree above, the user may choose to view a course or export a timetable. Both actions are optional, (note the *O* used to indicate this), but may also be done as many times as the user pleases, (note the use of the * symbol). However, at least one action must be taken before the user can leave the system because of the *then* keyword before the state 'Leave' in the task tree. If the user decides to enter the course view, they will be presented with a pop-up screen on desktop and tablet, or an entirely new screen on mobile. Once in this state, the user is free to modify their course selection and configuraion as many times as they please. (In the task tree, these two actions are modelled to occur in parallel, through the use of the // symbol). The screen of available configurations for mobile includes a reduced amount of options to avoid overcrowding the UI. If the user decides to export a particular timetable, they will encounter a new screen, displaying buttons for printing and exportation. As soon as at least one action has been taken by the user, they may leave the system. According to the task tree, this may take the form of a traditional logout process. This is optional however, (again, note the *O*), because the user may choose to just close the site itself without logging out in the standard way. #### b. Justifications   Diagram [Appendix A] shows the domain model for the data view. The data view consists of a menubar and a courses-view. Firstly, the menubar consists of several navigation items. These items are used to navigate to the lesser utilized actions of the products. This is, as shortly explained before, in accordance with minimal actions and concision. Secondly, the courses view consists of the actual courses and the week navigator. The courses have a date indicator and a column which contains the courses for that day. These courses only contain the name and the room to have a lower level of information density. The navigator contains simple buttons to navigate back and forwards weeks. This creates flexibility in functionality. Namely, the user interface can be reused in mobile and tablet views. ### Interaction scenarios   #### Scenario 1 ##### Goal Check specific courses in the schedule. - Open ADEv2 (*shows login interface*) - Login (*show the schedule if the login phase is successful* otherwise *show an error and ask again*) - Click on "select course" menu (*show the available courses*) - Select courses from the list (*courses appears in the schedule*) - Click on logout (*close the schedule*) - Close the page #### Scenario 2 ##### Goal Export schedule to CalDav and create a configuration. - Open ADEv2 (*shows login interface*) - Login (*show the schedule if the login phase is successful* otherwise *show an error and ask again*) - Click on "select configuration" menu (*show the available parameters and save configurations*) - Select configuration from the list (*configuration changes appears on the schedule*) - Change parameters of the current configuration (*configuration changes appears on the schedule*) - Save and close the configuration (*close the configuration menu and show the schedule*) - Click on the "export" menu (*show the export options*) - Click on "export to CalDav" (*switch to CalDav*) - Close the page #### Scenario 3 ##### Goal Check the schedule quickly. - Open ADEv2 (*shows login interface*) - Automatically logs in (because connection is still active) (*show the default schedule and configuration*) - Close the page ### Self-assessment   Our design has many advantages over the previous system, but some compromises had to be made throughout the design phase. Many of the problems associated with the original version of *ADE* are tackled. The new system features an intuitive and adaptable UI, attempting to make it vastly more user-friendly according to the interviewee input. The user is no longer bombarded with irrelevant information whenever they attempt to access their schedule. *ADEv2* may be used across different devices and first-time users should easily be able to navigate the system. Making the new design as intuitive as possible was a priority, based on feedback from participants in the field study. Whilst this approach ensured that the drawbacks of *ADE* were largely overcome, it led to the creation of a system without a vast array of options. This compromise was consciously made – prioritizing an uncomplicated UI meant sacrificing several features. That being said, key-binding will allow experienced users to interact with the system more efficiently and in their own way. *ADEv2* has many strengths, such as compatibility across devices and an intuitive UI, as mentioned already. It also allows the user to configure their custom, relevant timetables. Such schedules may then be exported in order to be integrated with various calendar systems. This will be a widely used feature, based on the fact that it was frequently requested by participants in the field study. One disadvantage of the simplicity of the UI is a possible lack of clarity about certain actions. To the user unknown icons trigger required tasks. In this case, mouseover effects partially resolve some of the issues. This topic requires experimentation. Despite its potentially limited options, this new system is an undeniable improvement over its predecessor.  ## Appendices ## Appendix A: Domain Model ![](https://i.imgur.com/UHtuLtz.png)

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.