# A Visual Language for the Solid Databrowser

There has been a call for a Visual Language for Solid, in the style for example of the style of airbnb's blog on this.

It is true that solid apps using the solid store will typically end up coming from many different places and using many different languages. The stores and their generic API are designed to be universal, so that any data at all can be put in Solid. So one would not want to mandate that all client apps use the same UI language everywhere forever.

However, there is a default app, the databrowser which ships as a sort of basic operating system on many solid servers. Its language is interesting for three reasons. Firstly, because it has been thought about: databrowser is a solid app, and so it is an example of the visual language which it ended up with; secondly because it is useful for people designing for the system to be able to design in the language, and thirdly because lots of people have suggested that the databrowser UI could be improved, this may give a focus for improving it! There are below as many questions asked and unanswered as answered.

Some of the challenges in the UI of solid are that in the Solid world any app can have any data about anything -- from linked data attitude that anything can say anything about anything. Also as everything has a URI, anything can be linked to anything else.

## Panes

Something like person may start off with just having, say, contact information, about themselves, but then someone may add more information about their events, or messages, or tasks, and so on.

Panes are alternative views of a thing -- a think like a person or an event or a photo or a track. They are produced by different software modules, or apps.

### Pane layout

Panes are rectangles -- HTML divs. They were originally designed to make the most powerful use possible of a large screen.

#### Large screen

In solid panes, when used with a lot of screen real estate, a pane starts at the top left corner of the space, and works downward, but isn't afraid of of using the whole screen.

Panes do nest inside each other, but not like cute wooden window panes. An outer pane is free to put inner panes anywhere it likes to make sense and communicate well with the user.

Panes should be tested on large screen sizes as well as medium and small. A user's journey might take them through some navigation steps to find after a while a picture, or map, or a chart, which really benefits from using up all the rest of the space. It can be very frustrating when you find such a resource, you have a large screen, but a developer at some point slapped a max width which suited their screen at the time. Don't let the push for mobile first leave the folks who delight in their huge screens facing a mobile-equivalents experience on them!

#### Small screen

On a small screen, by contrast, they should typically take the whole screen, but allow swipe navigation around a grid or a tree. There is (2018-11) no code, but some UI mockups have been done for the databrowser on mobile. The trick as ever is to re-use existing language the users will have come across where it exists and works. When looking for example at a attachment document in the materials of the meeting, you have to be able to vertically swipe through the pages of the document, so it is logical to horizontally swipe though the different documents, but to the left of the leftmost document instead a document being a navigation space at the top level of the meeting between between scheduling, location, attendees, program, materials, and notes.

A challenge in Solid is that things link together and contain each other in a very free way. Whereas a Meeting App might have a nav-bar with the top level, [scheduling,location, attendees, program, materials, notes], in Solid the meeting may be a property of the person who you had the meeting with, and the nav bar be full things to do with the person. Not insuperable problems, but things to think about.

While mobile first is an alternative in the works, the original "power user first" mantra. As it does so, it may invoke other panes to display things related to the main subject.

## Edit anything - edit state

An attitude of the solid project has always been that collaboration between different people and groups is the goal. Therefore, wherever a user can view data they should be able, if authorized, to edit it too. To make it clear when this is possible, when it is happening, there are common colors for the different states of an input field

Read, unedited | Black on white
Read, not editable | Grey on white
Edited, good syntax | Green on white
Edited, bad syntax | Red on white
Saving back | Black on grey
Error saving back | Black on pink
Saved back to the web | Black on white

Examples of this are the fields in the form system, and the source editing pane. The users should get used to any black on white data being in sync with the web of data, and the system should always make sure to indicate with the colors above when it is not the case.

When there are network errors saving user data, never through the data away!

### Link to anything: Identity

In Solid, you can store connections between anything any anything. This doesn't always make sense, and may not always be useful, but we do have to have a UI language which allows this.

In a desktop environment, drag and drop is more or less ubiquitous. Anything can be dragged, and many things can be dropped on to. You can drag a person into a group to add them to a group. You can drag a person, or a group, or both, into the Sharing control to give them access to something, dragging them around between the different roles until they have the right form of access. You can drag things from outside the solid world into a solid: a desktop file into a solid solid folder to upload it; you can drag a URI from the URL bar icon of a browser into the solid world to connect in the thing you were looking in the browser. You can drag things out of the solid world .. for example if you drag some item in a complex databrowser display onto the tab bar of the browser just past the tabs, it will open a new tab viewing that specific thing.

As anything is drag-able, it must be consistently clear what that thing is. One common widget used in many lists is a tree-part widget with an icon on the left, a label in the middle, and some control buttons ("delete this", "visit this", ...)in the right hand part.

The icon is ideally set to a specific image of the object, like a mugshot of the person or logo of a company or project, otherwise set to an icon for the class: a generic icon for a person, a group of people, a document, and so on.

Where things are draggable in the desktop world, in the mobile world they need to have places to press on in various ways to capture their identity. The "Copy link" aka "Copy URI" functionality is very common UI language. Will the solid world be able to get away with just that, or will it need more "Mark this" where the marked thing is a second clipboard; or "Push this" to push things onto a stack? Should the things selected form an editable cache of interesting things which the user can pick from as the to all kinds of operations later? Should the user be able to scroll back through all the things they have every copied to the clipboard? Today's mobile clipboard is often not powerful enough, when you often need to copy the phone number and access code or flight number and reservation number at the same time.

There is some design to be done here.

### Button Color Language

We have tried to be consistent with colors:

Green | Add Data
Red | Remove Data
Blue | Commit, eg send a message
Black & White | Change view, delete view

One inspiration was the Mac OS X contact view at the time, where a quite readable view of someone's contact details was annotated with little green pluses and little red minuses which made it clear where things could be changed and how to change them.

The color language is that anything which does not add or delete data, or commit the user to something, is monochrome. We have resisted the temptation to us pretty colored icons -- even the Rainbow icon used for sharing. We may totally revisit this, and one day roll out a version with all the icons in really interesting colors representing the class of object or the domain in some way, but that is not the current language. We could also make it a user preference of course.

The discipline of making the databrowser navigation of folders and lists and people and meetings be essentially monochrome has meant that resources like pictures and icons

### Icon shapes

Icons should be simple, a black drawing on a transparent background. All should be monochrome black on transparent exact for the few green, red or blue corresponding to the button color language above.

We use the Noun project as an excellent resource. We pay a fee so that there is no obligation to give attribution of the authorship, but still a way to extract all the authors and list them as credits with links back would be awesome.

Icons should use SVG, not PNG or JPEG or GIF. Currently they are all in a single module in solid-ui but ways of making that more modular are possible in future.

Icons are used for panes (views), actions, and object. The graphical form representing an object should be taken, in order or preference, from:

1. A foaf:icon for the thing
2. Any other image for the thing itself from data, such as foaf:image, vcard:photo, etc, etc
3. An icon corresponding to the class of the thing, like Person, Group, Meeting, etc

### Labels: use the ontology

The goal is of course to make everything as accessible as possible with people with different abilities, using different devices. The internationalization goals are most easily met by using icons rather than text. Some people, however in fact prefer text.

The data in the system is RDF data, and in RDF, classes (like Person) and properties (like friend) have URIs. There are files out there on the web with information about them, which includes a human-readable label for the property.

The labels are often in English, but on a good day, in many languages. This means that if the UI generates up its labels from the ontology you get potentially internationalization for free, if there are alternative languages available in the ontology.

This has the benefit that it scales quite well, in that effort put into translating the ontologies, which can possibly be crowd-sourced, pays off as an immediate benefit for anyone

Action | Button label
Create new instance of C | ✨New (label(C))
Create new thing related by property P | "New" icon + label(P)
Visit thing(s) related by P | label(P)

In general a good rule when coding to to to try to involve introducing any text for the user which would have to be translated. Use a combination of icons and text looked up in the ontology.

Another idea is to make a composite icon out of the verb and the class, so "New Group" would be a compose icon of a small green plus (or star) superimposed on the icon for a group of people. This is quite common in desktop software, so the language will be understood.

(Because you may want the ontology to be available offline, it may be a good idea to import a copy into code. How to do that is beyond the scope of this note)

### Link to anything: Relationship

Demonstrating the relationship between two things typically involves a table with the relationship in the left and the object of it, or value, on the right. That labelled form field language is so ubiquitous in computer UI, we use all over. Having a user preference go flip it from left-right to right-left in locales where the user is reading everything right-left would be ideal.

Relationships also show up in column labels for tables. Just the same language applies as for a form field label.

It is often easier to have a recognizable for icon for classes, like Person, Group, Adult, than for relationships like friend, child. So icons tend to less useful for expressing relationships than classes. However, when really there is only one main property linking thinks of class C to things of class D, then one use the icon for the class. If the only type of relationship a person can have an event, then the list of attendees can be given the person icon.

### Link to anything; Potential relationship

More complex is the question of how to allow the user to see what potential relationships are available. As you drag in an object A to a drop target B, how do you know what relationship you are going to express? One way is for the drop zone mutate into a set of triage drop zones: Drop here to make this person and invitee, here an attendee, here an organizer. Another way is to just assume a default relationship, invitee, say, and then allow the user to edit that once they appear in the list.

There are programs which do that -- but they are very bold about explaining to the user what is happening: large fonts in the labels. Fortunately the ugliness of the labels is temporary just until the user finishes the drop.

The original tabulator code had a feature to allow any new data to be added to a form-like view, where the predicate was a pop-up choice of all the properties which logically were reasonable to use on the class of subject. Then the range of the property chosen would be looked up in the ontology, and the type of UI for the object of it would be selected from that.

The same choice in fact occurs when you are editing a form, and you add a new field.

###

## Making up panes: Widgets and Forms

Panes are the largest in the stack of UI systems. They are implemented in terms of lower level things. IN the case of the solid-panes solid-ui stack, the panes are implemented using widgets of various sizes , and forms make out of widgets.

A form is defined in the RDF data model. Typically a form is made by hand in Turtle, or it can be edited using the form-editing form.

## Fonts, Font Size

### No Style Sheets

The classic way to make a web app is with an HTML markup file, a CSS style sheet and a JS script. When you build modular web apps with modularity in different levels./ But CSS style sheets have the problem that they are global. Global in the sense if the document, that you can't attach them (2018) to a subtree, only the whole document. (Never mind shadow DOMs). The problem of distinguishing which parts of the style sheet should apply to which parts of the tree, which types of element, and the elements created by each widget, leads ttheo, in big UI frameworks, a huge complex language of classes which are attached to elements.

The databrowser does have a global style sheet, and it sets classes for some early panes, but now the goal is to reduce the dependency on it to zero.

### Font Size

Legibility is really important. If your over-cute font means that ageing people can't read it, drop it and go with something normal.

- Where you don't need to specify something, inherit it from enclosing DOM elements.

Font, font size, color, background color,

- Where a widget must have a certain style, inject it directly from the JS script.

There is style module which has some JS variables for things like input element style so that can be shared through the code, rather than using global CSS which typically involves a lot of complexity and hard coordination between CSS writers and JS writers.

## Conclusion

That's it, folks.

Edited with BlueGriffon with thanks to @glazou