ARK2/UX - Revision history

John Layt: /* Map View */

2016-12-15T15:07:11Z

‎Map View

John Layt: /* UX */

2016-12-15T14:51:12Z

‎UX

John Layt: /* Configurable Views */

2016-12-14T20:49:58Z

‎Configurable Views

John Layt: /* Configurable Views */

2016-12-14T20:26:53Z

‎Configurable Views

John Layt: /* Data Schema */

2016-12-14T20:17:22Z

‎Data Schema

John Layt: /* Generic Pages */

2016-12-14T20:12:27Z

‎Generic Pages

John Layt: /* Data Schema */

2016-12-14T20:05:38Z

‎Data Schema

John Layt: /* User Profiles */

2016-12-14T18:59:19Z

‎User Profiles

John Layt: /* Field Recording */

2016-12-14T18:46:06Z

‎Field Recording

John Layt: /* UX */

2016-12-13T22:58:51Z

‎UX

@@ Line 87: / Line 87: @@
 === Map View ===
-* OpenLayers
+Spatial data and GIS is core to archaeology, but often in a way that has more in common with CAD than most websites. While some simpler forms of data are recorded, such as find spots or site addresses, most spatial data is a detailed and precise plan of all the contexts in a site drawn to 25mm accuracy. This data needs to be displayed in a way that can help with data analysis, such as how different objects relate to each other, as well as be attractive to a wider public.
-* Display advanced search results?
-* Spatial Search
+OpenLayers is used to display spatial data, both embedded as a subform in an Item View, or on a separate page showing a Collection of Items. Spatial search and interactive editing are also required, but full-blown spatial analysis is done in a proper GIS package that can make calls to the ARK api to obtain the data.
 === Advanced Search ===

@@ Line 1: / Line 1: @@
 = UX =
-ARK, the Archaeological Recording Kit, is a web application for recording, analysing, and publishing archaeology data. ARK provides a very flexible platform akin to a CMS to allow different clients to configure their site to meet their data recording needs. This flexibility applies to the UX and UI as well as the data schema.
+ARK, the Archaeological Recording Kit, is a web application for recording, analysing, and publishing archaeology data. ARK provides a very flexible platform akin to a CMS to allow different clients to configure their website to meet their data recording needs. This flexibility applies to the UX as well as the data schema.
-ARK1 is largely custom code that is showing its age and hard to customise. ARK2 is a ground-up rewrite to bring ARK into line with modern web technology including a REST API, while also making it easier to configure and maintain. ARK2 will also enable ARK to be offered as a hosted service.
+ARK 1 is largely custom code that is showing its age and hard to customise. ARK 2 is a ground-up rewrite to bring ARK into line with modern web technology including a REST API, while also making it easier to configure and maintain. ARK 2 will also enable ARK to be offered as a hosted service.
-While clients are able to build custom web or app interfaces using whatever technology they prefer, most will choose to use and possibly adapt the default Bootstrap/Twig web interface which needs to be both feature-complete and flexible, albeit at the cost of some efficiency. They are also likely to use variations on the standard 'Site Recording' data schema with 'Sites' or 'Projects' at the top level, as will the hosted ARK-as-a-service, so the default UX should be weighted towards that scenario.
+While clients will be able to build custom web or app interfaces using whatever technology they prefer, most will choose to use and possibly adapt the default Bootstrap/Twig web interface which needs to be both feature-complete and flexible, albeit at the cost of some efficiency. They are also likely to use variations on the standard 'Site Recording' data schema with 'Sites' or 'Projects' at the top level, as will the hosted ARK-as-a-service, so the default UX should be weighted towards that scenario.
 Note that 'Site' is a term often used in archaeology to define a geographic area of interest or excavation, to avoid confusion we will try refer to 'An ARK Website' and 'An Archaeological Site' wherever possible.
@@ Line 15: / Line 15: @@
 === Field Recording ===
-The primary use for ARK is recording archaeological data in the field, analysing the data in the office, and publishing the data online. It reflects the paper-based field recording systems originally used in Archaeology, being based around Registers and Forms, and is designed to replace part or all of a paper-based system. The UX primarily needs to support this field recording role, but be adaptable to other data recording scenarios both in archaeology, but also other potential uses such as conservation. The UX needs to balance the familiarity of the users with the paper-based systems with the improved workflows that can come from an online system.
+The primary use for ARK is recording archaeological data in the field, analysing the data in the office, and publishing the data online. It reflects the paper-based field recording systems originally used in Archaeology, being based around Registers and Forms, and is designed to replace part or all of a paper-based system. Field staff are often freelance or on short-term contracts, so the UX needs to be familiar enough for them to adapt to quickly. The UX needs to balance the familiarity of the users with the paper-based systems with the improved workflows that can come from an online system. The UX should also be adaptable to other field data recording scenarios both in archaeology, and also other potential uses such as conservation.
 [[File:ExampleRegisterSmall.png]]
@@ Line 38: / Line 38: @@
 Other archaeological objects can also be added to the model as required.
-As staff in the field excavate a site, they initially Register the basic details of contexts and objects using phones or tablets, and can then add more details as required. Staff in the office then process that data, such as putting the Contexts into Subgroups and Groups, before publishing the results. The results are mostly used internally for writing formal reports, but may also attract wider professional or public interest.
+As staff in the field excavate a site, they initially Register the basic details of contexts and objects using phones or tablets, and can then add more details as required. An alternative use model is to record on paper and later copy into the ARK. Staff in the office then process that data, such as putting the Contexts into Subgroups and Groups, before publishing the results. The results are mostly used internally for writing formal reports, but may also attract wider professional or public interest.
 == User Profiles ==
 * Anonymous - A member of the general public interested in browsing information about the archaeological site. Primary requirement is rich detail with easy navigation.
-* Field Operative - A member of staff recording and editing data in the field. Primary requirement is speed and simplicity of data entry in challenging conditions (protective gloves, rain, mud, etc), often only using a mobile phone..
+* Field Operative - A member of staff recording and editing data in the field. Primary requirement is speed and simplicity of data entry in challenging conditions (protective gloves, rain, mud, etc), often only using a mobile phone.
 * Field Supervisor - A member of staff supervising other field staff with supervisor-level site functions. Primary requirement is quickly and easily reviewing and editing data.
 * Office Operative - A member of staff in the office processing data. Primary requirement is full-featured but efficient data entry and editing, but also search and navigation.
@@ Line 52: / Line 52: @@
 == Configurable Views ==
-Just as the data schema is completely configurable by a website admin, so too are the views of that data. ARK combines a layout grid with content blocks known as Subforms. Each Subform usually contains a layout of data fields from the schema, but can also contain other elements. Subforms are usually used to arrange fields that are related, or share similar functionality. Different page views of the same Item can be laid out for different purposes, for example the Field Operatives data entry view may differ from the Office Supervisors data analysis view. Where this differs from standard CRUD forms is in the code functionality that can be embedded in a Subform. A different View of an Item can also offer different functionality for that Item.
+Just as the data schema is completely configurable by a website admin, so too are the views of that data. ARK combines a layout grid with content blocks known as Subforms. Each Subform usually contains a layout of data fields from the schema, but can also contain other elements. Subforms are usually used to group fields that are related, or require similar functionality. Different page views of the same Item can be laid out for different purposes, for example the Field Operatives data entry view may differ from the Office Supervisors data analysis view. Where this differs from standard CRUD forms is in the code functionality that can be embedded in a Subform. A different View of an Item can also offer significantly different functionality for that Item.
-Item Collection views, such as Table, List, Thumbnail, etc, can also be configured. In ARK1 the two main variants are currently Register and Search, but ARK2 will also define a standatd List view.
+Item Collection views, such as Table, List, Thumbnail, etc, can also be configured. In ARK 1 the two main variants are currently Register and Search, but ARK 2 will also define a standard List view.
 The core UX requirement is to define the relationship and navigation between these core generic pages, rather than the physical layout of the Item fields and Subforms. The current model is not integrated or consistent and leads to considerable confusion for users.
@@ Line 118: / Line 118: @@
 == User Security ==
-ARK2 will provide a very flexible User Security system using an RBAC model. Website admins will have a choice of registration and authentication options and the UX/UI should adapt to these as configured.
+ARK2 will provide a very flexible User Security system using an RBAC model. Website admins will have a choice of registration and authentication options and the UX/UI should adapt to these as configured. Login should work as either a page or a pop-up.
-* Register
+* Register (by self or admin)
 * Login
 * Optional Captcha

@@ Line 52: / Line 52: @@
 == Configurable Views ==
-Just as the data schema is completely configurable by a website admin, so too are the views of that data. ARK combines a layout grid with content blocks known as Subforms. Each Subform can contain another layout of the fields displayed by that Suborm. Subforms are usually used to arrange fields that are related, or share similar functionality. Different page views of the same Item can be laid out for different purposes, for example the Field Operatives data entry view may differ from the Office Supervisors data analysis view.
+Just as the data schema is completely configurable by a website admin, so too are the views of that data. ARK combines a layout grid with content blocks known as Subforms. Each Subform usually contains a layout of data fields from the schema, but can also contain other elements. Subforms are usually used to arrange fields that are related, or share similar functionality. Different page views of the same Item can be laid out for different purposes, for example the Field Operatives data entry view may differ from the Office Supervisors data analysis view. Where this differs from standard CRUD forms is in the code functionality that can be embedded in a Subform. A different View of an Item can also offer different functionality for that Item.
 == Generic Pages ==

@@ Line 52: / Line 52: @@
 == Configurable Views ==
-Just as the data schema is completely configurable by a website admin, so too are the views of that data. ARK combines the concepts of a layout grid with content blocks known as subforms.
+Just as the data schema is completely configurable by a website admin, so too are the views of that data. ARK combines a layout grid with content blocks known as Subforms. Each Subform can contain another layout of the fields displayed by that Suborm. Subforms are usually used to arrange fields that are related, or share similar functionality. Different page views of the same Item can be laid out for different purposes, for example the Field Operatives data entry view may differ from the Office Supervisors data analysis view.
 == Generic Pages ==

@@ Line 11: / Line 11: @@
 == Data Schema ==
-The ARK data schema is configurable using the concept of Modules. A Module can be thought of as an Object in the Object-Oriented model, a Resource in the REST model, or a table in the Relational model, with a set of data properties and relationships to other Modules. This schema is completely configurable by the website admin, but a number of pre-defined configurations for industry-standard recording schemas are available to use.
+The ARK data schema is configurable using the concept of Modules. A Module can be thought of as an Object in the Object-Oriented model, a Resource in the REST model, or a table in the Relational model. A Module has a set of data properties and relationships to other Modules. An instance of a Module is known as an Item. The schema is completely configurable by the website admin, but a number of pre-defined configurations for industry-standard recording schemas are available to use.
 === Field Recording ===

@@ Line 49: / Line 49: @@
 * Website Admin - An administrator of the ARK website. Primary requirement is basic admin functions, mainly user admin and vocabularies, but sometimes also schema.
 * System Admin - An administrator of the ARK install (Different from Site Admin on multi-site/multi-tenant installs). God.
 == Generic Pages ==

@@ Line 17: / Line 17: @@
 The primary use for ARK is recording data in the field, analysing the data in the office, and publishing the data online. It reflects the paper-based field recording systems originally used in Archaeology, being based around Registers and Forms, and is designed to replace part or all of a paper-based system. The UX primarily needs to support this field recording role, but be adaptable to other recording methods.
-[[File:ExampleRegister.png]]
+[[File:ExampleRegisterSmall.png]]
-[[File:ExampleSheet.png]]
+[[File:ExampleSheetSmall.png]]
 The main recording system used is called Single Context Recording in which various objects and concepts found on an archaeological site are recorded.