Prior to creating the portal it would be excellent to hear feedback and get suggestions for improvements or alternative layouts.
The first few most important end user pages are sketched below. The first thing to note and discuss is the simple layout with a single Stack Layout on the left.
An implementation using the suggested Stack Layout would be simple and similar to how an online email program is presented.
A left most column would allow the end user to select between the main sections of the site: Dashboard, Settings, Devices, Apps, and Resources. Each section would have an icon and label on the left. Some of the sections, such as the devices section would have a further tree type list on the left under the section heading.
An example of the Stack Layout is shown on the right.
The rest of the page area on the right would then contain the content relevant to the selected section. Some sections such as settings would be able to be contained on a single page and therefore not require any sub-section list or tree on the left under the section heading.
The sketches cover the login page that is always in English. (All other pages will be able to be localised.)
The Settings page has little data given that little personal information would be initially collected. The content on the right on all pages would flow, so could suit a more narrow mobile device as well as a desktop or laptop viewing screen size and aspect.
The dashboard is intended as a flexible first page to quickly show the end user a summary of their most important dynamic information. Some of the quadrants on the dashboard could be uniquely developed as apps (based on use cases) are added.
The media resource section is critical, and will likely have to be reimplemented with more design and usability that sketched here. The initial sketch is based on the boring but effective file explorer model, The user could sort all audio, video, image and documents. The initial sketch shows just a name field to describe the resource. More polished usable details could be added, potentially including things such as descriptions, previews, search-ability, keywords etc.
Most of the organisation of the worn devices, the hardware or Andoid bridges, and any beacons will occur with a tree list on the left within the Stack Layout section.
Details on the selected would then be sown on the right. Most fields other than name, would be informative and non editable. Improvement of the interface to include for example a chart showing battery life rather than a single current charge percentage could be added in the future as required.
The Apps section is not sketched but could include a simple list of all apps in the Stack Panel under the section. Any used apps would be checked in this list.
The currently selected app would show details on the right content area. Most likely some apps will have app specific settings. Most apps will also have the ability to populate a quadrant on the dashboard with results. Perhaps the end user could select which if any views of an apps results are included in the dashboard.
The dashboard would likely require a carousel to rotate quadrants should the user choose to display more than four quadrant result views.
It is not clear where options and information about the process of working through he ID steps in a structured course should go. Potentially a retreat or course section could be needed to clearly organise the steps in a program, the contemplations, active apps for that week, etc. Rather than try to guess in advance all required data, a don’t know mind-state is held. Keeping the site small, simple and clean leaves space to add some additional sections as required.
It is hoped that the same site would be used for internal stuff. A internal staff user would log in to the same site and be presented with more stuff for the additional more complex staff tasks. The additional appearance of more sections would occur based on the permissions and rights of the user who logged in. There would be once site that changes what is included based on the username.
It was initially expected that a row or two of toolbar buttons would be required, but perhaps for the end user things can be kept simple enough to not require any buttons.
The pages for the internal organisation of media resources, for design of courses, for management / inventory of Talisman, for site administration are almost certain to require the addition of one to two rows of context relevant buttons at the top.
The addition of many toolbar icons would likely make the management site more suitable for a landscape desktop or laptop browser, which should be acceptable.