UI Kit - Revision history

Kman at 16:43, 14 July 2020

2020-07-14T16:43:15Z

Kman at 00:16, 14 July 2020

2020-07-14T00:16:39Z

Kman at 23:39, 13 July 2020

2020-07-13T23:39:03Z

Kman at 23:38, 13 July 2020

2020-07-13T23:38:44Z

Kman at 23:26, 13 July 2020

2020-07-13T23:26:57Z

Kman at 23:11, 13 July 2020

2020-07-13T23:11:24Z

Kman at 23:01, 13 July 2020

2020-07-13T23:01:44Z

Kman at 23:00, 13 July 2020

2020-07-13T23:00:42Z

Kman at 22:56, 13 July 2020

2020-07-13T22:56:55Z

Kman at 22:47, 13 July 2020

2020-07-13T22:47:17Z

← Older revision		Revision as of 16:43, 14 July 2020
Line 22:		Line 22:

	With the model defined, the user flow describes how the model is transformed based on external events. The user flow is broken down into a set of steps represented by colored shapes and are connected to one another by arrows. In order to follow a step, a list of criteria must be met depending on type of step represented. When a step is followed a function is performed at which point the step is said to be complete and then every arrow pointing away from the step must be evaluated to determine the next step to go to. If a step has no arrows pointing out of it, then that step is said to be a terminal step at which point no further changes to the UI are possible.		With the model defined, the user flow describes how the model is transformed based on external events. The user flow is broken down into a set of steps represented by colored shapes and are connected to one another by arrows. In order to follow a step, a list of criteria must be met depending on type of step represented. When a step is followed a function is performed at which point the step is said to be complete and then every arrow pointing away from the step must be evaluated to determine the next step to go to. If a step has no arrows pointing out of it, then that step is said to be a terminal step at which point no further changes to the UI are possible.
		+
		+	In cases where a UI component is provided by the platform and already has an existing implementation, it may not be necessary to provide a user flow and instead the UI component can either reuse the existing user flow or defer the user flow to the platform. For example most platforms including HTML, macOS, Windows etc... already provide a text input field as well as a button, in those cases it is preferable to defer the user flow to the respective platform instead of redefining one. Only in cases where custom functionality or custom components are being created is a user flow required.

	Flow charts are documented using software available at https://diagrams.net		Flow charts are documented using software available at https://diagrams.net

← Older revision		Revision as of 00:16, 14 July 2020
Line 100:		Line 100:
	<br>		<br>
	<br>		<br>
		+
		+	===Example: Login form===
		+
		+	A login form's model consists of data representing a username and password that is input by the user, a state to store whether the user is in the process of logging in, and signals indicating whether the user has submitted their credentials or wishes to cancel a currently pending sign-in attempt. Its <code>model.txt</code> is hence structured as follows:
		+	<pre>
		+	Data:
		+	username: The username input by the user.
		+	password: The user's password being input.
		+
		+	State:
		+	status: The sign-in status of the UI, can be one of the following values:
		+	NONE - Default state.
		+	SIGNING-IN - The UI is in the process of signing in.
		+	REJECTED - The sign in was rejected, invalid username or password.
		+	UNAVAILABLE - The server is not available.
		+	SIGNED-IN - The sign in process succeeded.
		+
		+	Signals:
		+	submit: Indicates the user has submitted their login credentials.
		+	cancel: The user wishes to cancel the sign-in process.
		+	</pre>
		+
		+	The user flow for the login form is below:
		+
		+	[[File:user_flow_login.png\|Login example]]

@@ Line 97: / Line 97: @@
 <br>
-[[File:ui_kit_button.png|Button example]]
+[[File:user_flow_button.png|Button example]]
 <br>
 <br>

← Older revision		Revision as of 23:38, 13 July 2020
Line 89:		Line 89:

	An ambiguity is a step that contains multiple arrows that are simultaneously satisfied. A flow chart that contains an ambiguity is ill-formed and must be resolved. For example if a step <code>Q</code> has an arrow leading into an unconditional step (such as leading into an action or signal step), it must be the only arrow leading out of <code>Q</code>, any other arrow would necessarily introduce an ambiguity. If a step has multiple arrows leading into conditional steps where more than one condition is satisfied then that too is an ambiguity. Resolving such ambiguity is done by giving each arrow a priority.		An ambiguity is a step that contains multiple arrows that are simultaneously satisfied. A flow chart that contains an ambiguity is ill-formed and must be resolved. For example if a step <code>Q</code> has an arrow leading into an unconditional step (such as leading into an action or signal step), it must be the only arrow leading out of <code>Q</code>, any other arrow would necessarily introduce an ambiguity. If a step has multiple arrows leading into conditional steps where more than one condition is satisfied then that too is an ambiguity. Resolving such ambiguity is done by giving each arrow a priority.
		+
		+	===Example: Button===
		+
		+	The following is an example of a simplified button user flow. The button only responds to user events when it's enabled. Furthermore whether the user presses the enter key, or the space bar, or uses the mouse to click, the button responds to all such events with the same <code>clicked</code> signal. This allows more complex UIs to respond uniformly to a button without having to explicitly specify the manner in which a user interacted with it.
		+
		+	Finally note that no consideration is made for a change in the label or a change in the hover state since both of those changes are strictly visual, they affect the appearance of the button but do not in anyway affect the behavior.
		+
		+	<br>
		+	[[File:ui_kit_button.png\|Button example]]
		+	<br>
		+	<br>

← Older revision		Revision as of 23:26, 13 July 2020
Line 85:		Line 85:

	Similar to an action step, signal steps are followed unconditionally.		Similar to an action step, signal steps are followed unconditionally.
		+
		+	===Ambiguities===
		+
		+	An ambiguity is a step that contains multiple arrows that are simultaneously satisfied. A flow chart that contains an ambiguity is ill-formed and must be resolved. For example if a step <code>Q</code> has an arrow leading into an unconditional step (such as leading into an action or signal step), it must be the only arrow leading out of <code>Q</code>, any other arrow would necessarily introduce an ambiguity. If a step has multiple arrows leading into conditional steps where more than one condition is satisfied then that too is an ambiguity. Resolving such ambiguity is done by giving each arrow a priority.

← Older revision		Revision as of 23:11, 13 July 2020
Line 75:		Line 75:

	Both condition steps and test steps are technically interchangeable, the choice of one or the other is stylistic. One should prefer the test step in situations where a clear question can be asked and whose answer is a single value in which case the question is written in the body of the test step and each of the possible values or value ranges is a labelled arrow.		Both condition steps and test steps are technically interchangeable, the choice of one or the other is stylistic. One should prefer the test step in situations where a clear question can be asked and whose answer is a single value in which case the question is written in the body of the test step and each of the possible values or value ranges is a labelled arrow.
		+
		+	===Signals===
		+	<br>
		+	[[File:ui_kit_signal.png\|Signal step]]
		+	<br>
		+	<br>
		+
		+	The function of a signal is to inform other UI components about a change in state so that those other components can respond to such changes in the form of events. That is, a signal produced by one UI component is treated as an event by another UI component. For example, a button UI contains a <code>clicked</code> signal step indicating that the user clicked on it and in turn a form UI contains a corresponding <code>button clicked</code> event step where said form may respond by updating its data model.
		+
		+	Similar to an action step, signal steps are followed unconditionally.

@@ Line 22: / Line 22: @@
 With the model defined, the user flow describes how the model is transformed based on external events. The user flow is broken down into a set of steps represented by colored shapes and are connected to one another by arrows. In order to follow a step, a list of criteria must be met depending on type of step represented. When a step is followed a function is performed at which point the step is said to be complete and then every arrow pointing away from the step must be evaluated to determine the next step to go to. If a step has no arrows pointing out of it, then that step is said to be a terminal step at which point no further changes to the UI are possible.
 ===Start===
@@ Line 73: / Line 75: @@
 Both condition steps and test steps are technically interchangeable, the choice of one or the other is stylistic. One should prefer the test step in situations where a clear question can be asked and whose answer is a single value in which case the question is written in the body of the test step and each of the possible values or value ranges is a labelled arrow.

← Older revision		Revision as of 23:00, 13 July 2020
Line 71:		Line 71:

	Similar to the condition step, the test step can also be used to conditionally follow an arrow. The test step itself is followed unconditionally and the function of the step is to perform a test. Once the function is completed a set of labelled arrows pointing away from the step are checked and the arrow whose label satisfies the test is followed.		Similar to the condition step, the test step can also be used to conditionally follow an arrow. The test step itself is followed unconditionally and the function of the step is to perform a test. Once the function is completed a set of labelled arrows pointing away from the step are checked and the arrow whose label satisfies the test is followed.
		+
		+	Both condition steps and test steps are technically interchangeable, the choice of one or the other is stylistic. One should prefer the test step in situations where a clear question can be asked and whose answer is a single value in which case the question is written in the body of the test step and each of the possible values or value ranges is a labelled arrow.


	Flow charts are documented using software available at https://diagrams.net		Flow charts are documented using software available at https://diagrams.net

@@ Line 52: / Line 52: @@
 ===Conditions===
 <br>
-[[File:ui_kit_condition.png|Start state]]
+[[File:ui_kit_condition.png|Condition step]]
 <br>
 <br>
@@ Line 62: / Line 62: @@
 <br>
-If the current time is 6:30 PM then all three conditions are technically satisfied and so there is an ambiguity about which condition to follow. The numeric labels on the arrows are thus used to prioritize the conditions so that <code>current time >= 6:00 PM</code> is tested first and if satisfied then it's followed without considering the remaining conditions.
+If the current time is 6:30 PM then all three conditions are technically satisfied and so there is an ambiguity about which condition to follow. The numeric labels on the arrows are thus used to prioritize the conditions so that the conditional step <code>current time >= 6:00 PM</code> is tested first and if satisfied then it's followed without considering the remaining conditions.
 Flow charts are documented using software available at https://diagrams.net

@@ Line 55: / Line 55: @@
 <br>
 <br>
-A condition is a step that is followed if at the completion of the current step's function some condition is satisfied. If a step leads to multiple conditions then it must either be the case that only one such condition can possibly be satisfied or each arrow pointing out of the step and into a condition must be labelled numerically starting from <code>0</code> in which case each condition is tested in ascending order and the first condition that is satisfied is followed.
+A condition is a step that is followed if at the completion of the current step's function some condition is satisfied. If a step leads to multiple conditions then it must either be the case that only one such condition can possibly be satisfied or each arrow pointing out of the step and into a condition must be labelled numerically starting from <code>0</code> in which case each condition is tested in ascending order and the first condition that is satisfied is followed. For example consider the following user flow:
 Flow charts are documented using software available at https://diagrams.net