Implementing user interface in create section

[kyukyukyu]

Current UI on right column in create section consists of search box on the top, course cart box on the bottom, search option box and search result box. The last two boxes are displayed only when search box is focused. Well, this was thought to be pretty good design, but some problems have been encountered. They are

• Need for dsBackdrop directive. ui-bootstrap could have been not utilized for this.
• Making search result box stretched to fill the screen vertically.
• Computing the height of box group without CSS. Not implemented, the backdrop could not have been clicked in the box group area.

So, a new design has been considered for the user interface. Instead of moving around and making some boxes appear and disappear, there is only a single box. No backdrop. This box is stretched to fill the screen vertically, too. However, in this case, the height can be computed with CSS.

The box works just like navigation view in mobile apps. It has navigation bar on the top, and stepping in and out occurs inside it. Also, UIModalView-like transition occurs. Therefore, state definition and management for user interface is mandatory.

The user interface has one of these states:

1. create.course-cart
2. create.search
3. create.search-result
4. create.generated
5. create.detail

These are valid state transitions:

• 1 <-> 2
• 2 <-> 3
• 3 -> 1
• 1 <-> 4
• 4 <-> 5

Now, the way for state management should be defined. angular-ui/ui-router provides nested states and views. This feature is used for state management. (Bearing it in mind, the name of valid states are prefixed with create and dot character.)

For detail of design, take a look at design note below.

[kyukyukyu]

First, style Y271 should be followed for routing rules.

[kyukyukyu]

It seems better to define one more level which is child of state create. This makes it possible to distinguish two states: configuration for timetables, and showing the result of timetable generation. Therefore, instead of states defined before, defining these states is more encouraged:

1. create.conf.course-cart
2. create.conf.search
3. create.conf.search-result
4. create.result.list
5. create.result.detail

[kyukyukyu]

After timetable objects are generated using TimetableGenerator in state create.conf.course-cart, array of them can be accessed via TimetableGenerator, and state transition is made from create.conf.course-cart to create.result.list. By making TimetableGenerator hold the array, it becomes easy to manage the list of generated timetables during state transitions between create.result.list and create.result.detail. It is better than passing the array of timetables as state parameter.

[kyukyukyu]

Also, TimetableGenerator should calculate the credits, the number of class days, and the number of free hours of each of generated timetables. Each of these should be stored as value for these keys: credits, nClassDays, nFreeHours.

[kyukyukyu]

create.result.detail -> create.result.details.

[kyukyukyu]

Paging will not be applied to course search results. Instead, the results will be shown only up to 100 courses, and if the number of results is larger than 100, an information text will be displayed.

The reason why paging is taken away from course search results is difficulty on grouping courses by subject. Let's assume that there are five courses for one subject, and two of them are listed at the last of one page, and rest of them at the first of following page. With paging enabled, only the first three courses is displayed and grouped. Right after that, the following page is loaded, and it is hard to play with grouping new courses. Also, too frequent loading of new pages is not good for user experience.

So here's solution: disable paging on course search results, load slightly large numbers (about 100) of courses on single request, and inform user that there are too many courses to show. It is considered hard for users to check every entity in such large search results. Therefore, it is okay to show only some of the results and inform user about large search results.

[kyukyukyu]

Forgot to mention this. Naturally, each view for each state has its own controller, and the old controller CreateConfCtrl should be divided into multiple controllers. (Actually, I'm already working on it.)