inazca / progress Goto Github PK

Acceptance:

• task is displayed (given by the survey-JSON)

• given code is embedded in a code editor (code given by the survey-JSON)

• editing code is disabled

• the parts of the code are correctly marked (given by the survey-JSON)

Acceptance:

• header in theme color with project logo

• footer with all important data (only viewable when you scroll down)

• input field for entering the given survey code

• the input field provides instant feedback about if the code is valid or not

• button for confirmation

• confirmating a valid code will lead you to the route with the code ("/[code]")

• clear instructions

• can be accessed through the root-route ("/")

Edit: Footer will not be implemented now, maybe in a later stage of the development process

Acceptance:

• task is displayed (given by the survey-JSON)

• show given code embedded in a code editor (given by the survey-JSON)

• the editor is disabled

• marked part of the code is clearly visible to the user (use same color as for syntax highlighting)

• button with "legal expression" (active by default)

• button with "illegal expression"

• input field for giving a string term of the type

• when the button "illegal expression" is clicked the form should go invisible (best with an animation)

• button for submitting a solution

Implement some sort of simple logging.

Acceptance:

• log every button activity and time stamp for beginning of a task and end of a task

• write log into localStorage

Acceptance:

• implemented as a partial (ejs)

• user is shortly told in which phase the system is and why he needs to wait

• the user shall be aware that he can't interact with the system atm

• use of the progress bar of the Google Theme

• how long a wait view is displayed is determined by a JSON, gotten from the server

Should look like an E in any way

Acceptance:

• develop a new design for control buttons

• all control buttons should have a similar desgin

• give every control button a animation when shown

• give every control button a animation when hidden

Only one out of six users has noticed and used the previous and next buttons. To the other users the buttons were like invisible items. But when being confronted with them, they thought about them as a useful tool, that they just did not realise. One user that did notice the buttons was freightened of using them, as it could "destroy" something inside the app. As the buttons should provide useful functionality this problem will be of category "minor".

Solution:

• make buttons bigger

• add smaller points to the status bar for every view that can be reached in the evaluation phase

• solve bug that occurs when a waiting screen is right before the evaluation (prev not working)

Atm the prototype is using a Example-Object to get all the information needed for the survey. But for the 2nd evaluation the server has to give the correct JSON, corresponding to the participants ID to the client.

Acceptance:

• server is loading a JSON file from the data folder

• the loaded JSON file has the same name as the ID of the participant

• the server sends a JSON-String to the client

• the client parses the JSON-String

• the created Object is correctly connected to the app, so that all needed information is available to the cards

Most users expect, that for a illegal expression you can still give a answer to what type it would be. In consequence they also miss the buttons in the evaluate phase, as they can not see, if the other user has marked it as legal or not legal. And to a view users it was unclear if legal/illegal is referring to the whole code or only to the highlighted expression. As this is leading to misunderstandings of what the system is capable of or what it is doing in the background and leads to evaluations/solutions being submitted in a way they would not have if they understood the system, this problem is of category "major".

Solution:

• add legal/illegal-Buttons to Evaluation

• better specification of the task

• don't hide form when clicking illegal but show as disabled and change value to "unzulässig"

For some users the icons of the mark/unmark - buttons in the Syntax were not 100% clear and led to a short phase of thinking about which button has what functionality. Thus implicating, that the icons are not perfectly fitting and intuitive, even though it did not lead to any task failure.

Solution:
Search for new icons, that are more fitting. Maybe search through online text markers or similar applications and what icons they are using.

The users take a while, until they understand the meaning of the heatmap, because they are not looking at the legend soon enough. But this is only a cosmetic problem, as the discussion phase is lead by the survey conductor anyway, so he/she is in charge to explain the meaning of the diagramm and start a discussion about it.

Solution:
Not found atm.

For almost all users, the type display was perceived as a clickable button, but they did not really know what it would do or what it even showed. To one the phrase "Syntax highlighting" was confusing, he thought it would be a button to enable/disable syntax highlighting in the code editor. As it leads to some confusion and misunderstanding of the display, which would then fail it's task to provide orientation, as well as affecting every tested user, this usability problem will get the category "minor".

Solution:

• add a label to the display

• use a more decent grey for the icon circle

• add animation that appears when changing and hide in the beginning

This view will be used to display all content determined by the server in an integrated box.

Acceptance:

• can be accessed by entering a valid survey code on the home page or directly using the code as route

• a kind of reduced header (with animation)

• a box for displaying the given survey data is the rest of the page

• solve all subissues (label "surveyviewer")

Edit: status bar will not show with a reduced header as the header is not taking to much space and provides consistency

To Do:

• add description for which solution is currently worked on

• add absolute numbers of marking

• title of survey

• change "legal"-Button to "zulässig"

• give legal and illegal button a fitting color

• add colors for the status bar

• adjust type task description, so that the buttons give the answer to the task

• add a display to show how much percent marked a code as correct (md)

• fix CodeMirror height/width bug

• add a display to show which task type is currently being worked on

• add message to validation

• fit every card to the corresponding stage color and choose a fix color for the control buttons (use same color for header then)

Most users did not understand what the most controverse solution would mean. This is causing misunderstandings, confusion and makes it harder to understand the discussion view as a whole. For that this problem is of type "minor".

Solution:

• specify the word "controverse" in the hint

Some users expect that a compiler, will be used, when they submit the solution for the microtask solve phase. Some even suggested, that they would want this kind of tool, to test their code against errors like they would in a real coding situation. But as this did not lead to any confusion, delay or even failure of the task, the problem is only of a cosmetic category.

Solution:
not found atm.

While working on a survey the user should see, in which stage of the task he is situated. Therefore the following acceptance criteria are defined:

• a status bar is displayed above the surveycards

• the bar should show in which stage the user is atm (solve, evaluate, discussion, reveal)

• the bar should have an animation

• the current status should be displayed in a bright color and with another styling

• the current status should show its name

• the other statuses' names should be hidden

• the other statuses' color should be grey

Acceptance:

• change font-family to a fitting one

• add syntax highlight colors that fit with the app theme

Acceptance:

• task is displayed (given by the survey-JSON)

• given code is embedded in a code editor (code given by the survey-JSON)

• editing code is disabled

• marked part of the code is clearly visible to the user (use same color as for syntax highlighting)

• below that the correct answer is shown clearly visible

Acceptance:

• task is displayed (given by the survey-JSON)

• given code is embedded in a code editor (code given by the survey-JSON)

• editing code is disabled

• a heatmap is displayed behind the code (the heatmap is given by the survey-JSON)

• the code should still be clearly readable

New acceptance criteria:

• add a description for every color

Acceptance:

• task is displayed (given by the survey-JSON)

• show correct solution embedded in a code editor (solution given by the survey-JSON)

• the editor is disabled

Acceptance:

• task is displayed (same for every type determination task)

• the expression is shown without the code it's belonging to (highlighted with the highlight color)

• below that there is a histogramm with a bar for each answer that has been given (the complete histogramm is set by the survey-JSON)

• every bar should be divided into two areas corresponding to how often, percentually, the answer has been marked as correct

These are not criteria of the client, but the serverside diagramm generation:

• the "most correct" answer shall be shown at the most left and then the others in descending order

• when correctnes ties, the most chosen answer shall be preferred

Without reading the hint below the task, the users would not be able to understand how the buttons work at all. Thus showing that the way the mark/unmark functionality is not intuitive at the moment. This can lead to submitions that do not contain what users actually wanted and thus causing errors. Also the users will not even be capable of realising that they made a mistake in any way. With respect to this arguments this problem will be marked as "major".

Solution:

• rework the mark/unmark functionality in a more intuitive way

Search through similar applications and how they have implemented marking

A small part of users tends to believe that the given codes in the microtask discussion phase are not solutions from other participants but chosen by the survey conductor. This has no direct consequences, but still is a false perception of the systems status. As it is not leading to any errors or confusion this problem is of category "cosmetic".

Solution:

• add a superior description on top of the discussion cards, that now statistics to the solutions are shown

• change the name of the phase to "Statistiken" (name change only for user)

One user mentioned, that sizes of the cards and the submit-Button, in consequence also the correctness buttons are not fitting together. Sizes of buttons should be bigger and the padding of the survey-card at the bottom should be bigger. This is only a "cosmetic" problem.

Solution:

• make submit- and correctness-buttons bigger

• increase padding-bottom of the survey card

When selecting code from right to left in a syntax highlighting task and pressing the mark button, the code won't be highlighted. This is very confusing to the user and leads to a false understanding of the application's functions.

Solution:

• remove this bug

For the 2nd evaluation it is important that additional cards are displayed to make sure everyone knows what he/she should do when participating in the study.

Acceptance:

• add cards for survey filling containing the ID of the task and having a different "waiting"-icon

• add a card for filling out a ueq

• add a end card for thanking the participants and hinting, that they should not shut down the app or close the browser

Create a Material Theme and embed it in the project structure!

https://material.io/resources/build-a-material-theme/

The following things need to be done:

• use the correct "override"-syntax in every module

• delete unneeded ejs files and rename the remaining ones as well as changing their id to a class (microtask discussion uses one of the ids as css rule)

• unify script imports

• unify module imports

Acceptance:

• task is displayed (given by the survey-JSON)

• show given code embedded in a code editor (given by the survey-JSON)

• code is editable but given code can't be deleted

• button for submitting the solution

Acceptance:

• task is displayed (given by the survey-JSON)

• given code is embedded in a code editor (code given by the survey-JSON)

• editing code is disabled

• the given parts of the code are highlighted with the highlight color (parts are given by the survey-JSON)

• button for a highlight tool (with a selected highlight tool the user can highlight parts of the given code)

• button for a erase tool (with a selected erase tool the user can erase highlighted parts in the given code)

• button for submitting a evaluation

• after submitting a evaluation the client will switch to the next solution to be evaluated or will be lead to a waiting screen (what will happen is given by the survey-JSON)

• buttons for switching between already evaluated tasks

• the user can always go back to his own solution (already made changes in the evaluation should not be lost here)

• the solution of the user is not editable

A lot of users mentioned in any way, subtile or direct, that they would want to see their own solution in comparison to the revealed solution. As this is not misleading or producing any errors, as well as not delaying anything, but is only a nice to have, this problem is of category "cosmetic".

Solution:

• add own solution to the reveal views

Acceptance:

• give highlight buttons (mark, erase) a good design with a fitting icon

• animation of active and clicked should fit

Acceptance:

• task is displayed (given by the survey-JSON)

• below the task there are two code editors each having one complete solution (solutions given by the survey-JSON)

• codes are not editable

• the left solution is the solution that has been marked correct the most (solutions are given)

• the right solution is the most controversial solution, meaning the closest to 50/50 correct/incorrect (solutions are given)

• the code editors are framed with a fitting color

Some users found it to be very irritating that every card of a task type held the task description. They began reading it on every card until they realised, that it was the same task. Also reading the task again led to Evaluations being made, as if they would submit a new solution and not being aware of that they should correct a solution of somebody else. As this was very confusing to some users and led to a misunderstanding of the system, as well as tasks not being treated the way they should have been, this problem is of category "major".

Solution:

• make task description less visible on other cards then solve-cards

Maybe the task itself should even be hidden?

Acceptance:

• task is displayed (given by the survey-JSON)

• given code is embedded in a code editor (code given by the survey-JSON)

• editing code is disabled

• marked part of the code is clearly visible to the user (use highlighting color)

• the solution to be evaluated can be found below the code editor

• below the solution there are two buttons ("correct" and "not correct" implemented in any way)

• clicking one of those buttons will mark the solution as correct or incorrect and thus submit it

• marking the solution as correct or incorrect will lead to the next solution to be shown (transition would be best when animated)

• buttons for switching between already evaluated tasks

• viewing a already evaluated task: the button that has not been chosen when evaluating is displayed in a faint color, so that the user is clearly aware of what answer he had submitted

• the user can always go back to his own solution (already made changes in the evaluation should not be lost here)

• the solution of the user is not editable

The indentation of the given task and the user input is not the same. This is not leading to any problem, but still not pleasant to see. This problem is only of category "cosmetic".

Solution:

• unify indentation of vs-code and CodeMirror

The type of the expression was only chosen right by one user. Also it was not 100% clear to the users what they should type into the input field. It would be helpful for the users if they get suggestions or if they can only choose from a already given set of answers. This problem is not really leading to false answers, but it could cause problems with the discussion phase distribution, as almost every solution would be unique. For the UI this is only a "cosmetic" problem, but when linked to a completely functional backend it could lead to unwanted problems.

Solution:

• add a picker instead of the input field

• provide the picker with already given choices for the type

Acceptance:

• task is displayed (given by the survey-JSON)

• complete given solution is embedded in a code editor (code given by the survey-JSON)

• code is not editable

• below the solution there are two buttons ("correct" and "not correct" implemented in any way)

• clicking one of those buttons will mark the solution as correct or incorrect and thus submit it

• marking the solution as correct or incorrect will lead to the next solution to be shown (transition would be best when animated)

• buttons for switching between already evaluated tasks

• viewing a already evaluated task: the button that has not been chosen when evaluating is displayed in a faint color, so that the user is clearly aware of what answer he had submitted

• the user can always go back to his own solution (already made changes in the evaluation should not be lost here)

• the solution of the user is not editable

Most users have problems understanding what they should do, when the first evaluation is being shown. They tend to think of the system forcing them to correct their own solution if the solution is the same or are completely confused if a different solution is shown. And they are clearly not aware of the fact that they are shown a solution of another participant. Also some users thought they see the solution of "5" other participants and not the solution of participant 5, showing that this is also not really clear. And also they were confused by the same task description being displayed again. Some users mentioned that the correctness aspect of the other evaluations really helped them understanding the working task.

Solution:

• make the Evaluation task more visible

• make the the evaluation task clearer by mentioning that this is a participants solution

• make syntax highlight evaluate also a correctness evaluation

Acceptance:

• task is displayed (given by the survey-JSON)

• the given Code is displayed in a code editor(given by the survey-JSON)

• the code editor is not editable

• button for a highlight tool (with a selected highlight tool the user can highlight parts of the given code)

• button for a erase tool (with a selected erase tool the user can erase highlighted parts in the given code)

• the user is awar of which tool is currently selected

• button to submit solution