Demo Panel

The demo panel shown below was sent or display at the 2017 OMIP meeting.

OLYMPUS DIGITAL CAMERA
OLYMPUS DIGITAL CAMERA

The panel enables pushbutton triggering off events rom three key use cases to be seen and felt on the talisman prototype.

The demo panel also played a short audio file introducing the Connected Sangha project, and the Talisman. Videos of the panel were recorded but not able to be included within this post.

Advertisements

Portal (early beta) released

An initial release of the portal has been made to http://www.insightdialog.org

This shows the navigation with the stack of panels on the left hand side.

Beta

The site is running on a staging server and not a production server. The domain http://www.insightdialog.org is used to stage releases as features are added.

As a staging server it should be expected that any data entered could be lost at any time due to a new release being staged. A staging server could also be expected to be unavailable during the development process.

Currently two user accounts have been created. The first is an end user called Joe Bloggs who can login with username joeb and password pwd – in a production release secure passwords would be used.

The second user has the login username of kramer and the password of pwd and is permissioned as a member of the staff group who will be able to undertake other functions such as managing resources / audio etc.  In this release the only feature completed is the left hand stack layout navigation. It can be observed that different features in the left stack layout are available depending on the type of user that is logged in.

The flag icon in the toolbar can be clicked and the locale (country and language) can be changed. This results in the translated content appearing. All translation uses Googles machine translation, and 40 languages are available, although Perhaps only French was actually translated in this release.

The slow initial login will drastically speed up. The messages showing the resources, translations will not appear when the portal is released to production.

The slow redraw of the stack will also disappear in future release and will be quicker when sections are chosen.

This release is to show the navigation style, and to start the ongoing staging of releases as development continues. Significant internal geekery was completed to get the first page up. Additional features and pages will now be released.

 

 

 

 

 

 

Initial Possible Portal Page Sketches

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.

Login and Dashboard

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.

Stack PanelAn 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.

Settings Devices

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.

Media and Bridge

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.

Potential Hardware Bridge module

In the Transport Layer document, the requirement for a dedicated hardware Bridge was discussed.

MH-ET-LIVE-ESP32-Development-Board-WiFi-Bluetooth-Ultra-Low-Power-Consumption-Dual-Core-ESP-32

This device would require locating some sort of WiFi module to connect to the internet, and a Bluetooth 2.0 radio to communicate with the Talisman radio.

Above is a photo of a hardware module that does everything required, readily available at low cost, and easily programmed to act as a relay bridge.

This ready assembled module includes a WiFi module, a microprocessor to control the basic relay of the messages, and a Bluetooth radio. It is to be confirmed that the Bluetooth Radio is compatible with the 2.0 and BLE versions, which means this unit could support current Bluetooth 2.0, and also any future Bluetooth BLE iPhone radios.

The unit is available already assembled, and can be powered by simply plugging any readily available phone charger cord into the USB charge type socket on the module. The socket to plug the USB power cord is seen on the right of the unit half way along the short side. The socket accepts the standard slim USB cable used for Samsung phones etc, and appears in top down view as a silvery rectangle in the photo (between the EN and BOOT white lettering).

The unit could be very cheaply enclosed in black shrink plastic. There is no requirement to solder anything onto the unit. One end with the power USB socket would remain visible.

A sample of this device is being shipped to Allan, and if it is as listed would immediately fulfil all the current (and future) requirements of a dedicated Hardware Bridge.

This is excellent because it could remove the need to design our own Hardware Bridge circuit board, remove the need to source components and locate an assembly factory.

The unit can be obtained in single units, or hundreds of units from China from multiple suppliers under $8 USD per unit, delivered. The unit would require the program that would relay the data to be loaded into each unit using a cable. This is a simple plug the cable and click a program button operation that does not necessarily require an electronics person with soldering skills.

The end user would bring their home WiFi network name and password to the induction event. They would then be guided through a very very simple process where they enter these two pieces of information into their Hardware Bridge. This could be done very simply by browsing to the Hardware Device using any mobile phone and entering the network SID and password into two fields on a simple web page.

The settings for their home WiFi network would then be stored on their device.  Once home, the user would find a spare wall plug pack used for charging a cell phone, plug the cable into the Hardware Bridge, and place the unit somewhere in their house out of the way.  They would not have to do any else.

(Allan also ordered a range of Bluetooth BLE modules to allow testing what hardware would be required to support iPhone bridge. Any iPhone Bridge would require a redesign of the Talisman PCB to accomodate a different iOS capable Bluetooth BLE (not the existing Bluetooth 2.0) module.  A selection of various available Bluetooth BLE modules from each of the major Chinese manufacturers was ordered.)

Pseudo Talisman (with BT)

This is the Pseudo Talisman that simulates all the bluetooth radio activity that would be transmitted and received by a final Talisman.

This device will enable the development of the Android Bridge prior to the completion of a Talisman. The device allows imitation of the data that a Talisman would send over the Bluetooth 2.0 radio.  The device also allows capture of data sent from an Android Bridge to a Talisman.

OLYMPUS DIGITAL CAMERA

Full control over the Bluetooth radio allows recreation of events involving power cycling of the radio, changing modes of the radio, detection of pairing status of the radio and data sending and receiving.

There are two identical devices, one for sending to Nadar and one for Allan.

The device does not have any screen or physical buttons, and makes use of a serial link provided via the black USB cable. The device appears as a serial port. A set of commands is sent to the device over a serial port. An example command would turn power on or off to the radio.

bluetooth-pseudo-talisman.jpg

Any activity detected by the Pseudo Talisman Bluetooth Radio is echo-ed to the serial port for viewing in any laptop serial terminal application.

Any extensions or new features could be added via a firmware upgrade in the Pseudo Talisman. The Pseudo Talisman uses the cheek and cheerful Arduino Nano 3.0 device (board with the USB cable), a relay to switch power to the radio (board with the blue box), and a Bluetooth radio identical to the module used in the Talisman (third board with all the wires coming off the end.