WebJive allows the user (via GUI or config file) to configure addresses and everything is needed to identify the target Tango server and devices. And WebJive accepts the device description that Tango exposes, and detects if something cannot be understood (by signalling something detailed in the log and something more synthetic in the UI). This "detect if something cannot be understood" means that WebJive should cope with erroneous input provided by the user and communications errors between WebJive and Tango, and provide meaningful error messages (see below). At the end of this feature a member of the BUTTONS team uses WebJive to show how an engineer would go throw the task of building a UI for those Tango devices using the widgets that are available now for WebJive. As per Nick's late addition (done today 2019-03-11) it is necessary to provide the core of a user documentation. "Core" means to prepare the skeleton of a user manual. It should allow a novice user to understand how to launch WebJive, how to "link" it to a Tango server, how to make sure that the connection works, and 1-2 examples of documentation on what a plotting widget does (for example with some screenshot included; possibly some very short video clip, "How to ..." style, less than 1 minute long). Notes No changes are expected in the functionalities offered by the WebJive visual editor (selection and placement of widgets, editing of their parameters, ...). User documentation should be prepared in RST, to be included and (automatically updated) into the Developer portal. In the long run (not part of this feature) however such user information should be part of WebJive itself, rendered by the application itself when the user presses a "?" button. The documentation in the portal and that part of WebJive should be produced from a single source, RST files in the WebJive codebase. On error messages. It is a usability good practice to write error messages that explain in a concise way to the user WHAT happened (especially with respect to the work done so far by the user), WHY it happened (especially if the error is due to user input), WHAT needs to be done to recover (if the error is due to the user and if the user can do anything at all to recover; this includes suggestions on how to produce correct input), WHAT to do otherwise (contact somebody? wait for some event?). The user should be able to recover from most/all the error situations, possibly by undoing past actions.