Skip to content

Commit ad28739

Browse files
author
Tim Berners-Lee
committed
First draft of Visual Language note
1 parent 2c096af commit ad28739

1 file changed

Lines changed: 327 additions & 0 deletions

File tree

‎Documentation/VisualLanguage.html‎

Lines changed: 327 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,327 @@
1+
<html>
2+
<head>
3+
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
4+
<style type="text/css">
5+
body {
6+
font-family: Trebuchet MS, Palatino, sans-serif;
7+
color: black;
8+
background: white;
9+
margin-left: 3em ; margin-right: 2em;
10+
}
11+
p , ul, ol { text-indent : 0em ;
12+
margin-left: 0em ; /* a bit of white space */ }
13+
pre { margin-left: 1em; background-color: #eee; padding: 1em; font-size: 120%;}
14+
15+
table { border: collapse; }
16+
td { background-color: #eee; padding: 0.3em;}
17+
18+
li { text-indent: 0; margin-bottom: 0.5em;}
19+
h1 { text-align: center }
20+
h2 { font-style: bold; margin-left: -1em; }
21+
h3 { font-style: bold; margin-left: 0em; }
22+
h4 { font-style: italic; margin-left: 0em; }
23+
24+
address { text-align: right }
25+
a:link, a:active { color: #00e; background: transparent; text-decoration: none; }
26+
27+
a:visited {color: #529; background: transparent;}
28+
div.intro {margin-left: 5%; margin-right: 5%; font-style: italic}
29+
pre { font-family: monospace }
30+
a:link img, a:visited img { border-style: none }
31+
32+
tt { font-size: 120%; background-color: #eee; padding: 0.1em }
33+
</style>
34+
</head>
35+
<body>
36+
<h1>A Visual Language for the Solid Databrowser</h1>
37+
<p><br>
38+
</p>
39+
<p>There has been a call for a Visual Language for Solid, in the style for
40+
example of the style of airbnb's blog on this.</p>
41+
<p>It is true that solid apps using the solid store will typically end up
42+
coming from many different places and using many different
43+
languages.&nbsp;&nbsp; The stores and their generic API are designed to be
44+
universal, so that any data at all can be put in Solid.&nbsp; So one would
45+
not want to mandate that all client apps use the same UI language
46+
everywhere forever.</p>
47+
<p> However, there is a default app, the databrowser which ships as a sort
48+
of basic operating system on many solid servers.&nbsp; Its language is
49+
interesting for three reasons. Firstly, because it has&nbsp; - The
50+
databrowser is a solid app, and so it is an example of the visual language
51+
which ended up; secondly because it is useful for people designing for the
52+
system to be able to design in the language, and thirdly because lots of
53+
people have suggested that the databrowser UI could be improved, this may
54+
give a focus for improving it! There are below as many questions asked and
55+
unanswered as answered.</p>
56+
<p>Some of the challenges in the UI of solid are that in the Solid world any
57+
app can have any data about anything -- from linked data attitude that
58+
anything can say anything about anything.&nbsp; Also as everything has a
59+
URI, anything can be linked to anything else.&nbsp;&nbsp; </p>
60+
<h2>Panes</h2>
61+
<p>&nbsp;Something like person may start off with just having, say, contact
62+
information, about themselves, but then someone may add more information
63+
about their events, or messages,&nbsp; or tasks, and so on.&nbsp; </p>
64+
<p>Panes are alternative views of a thing -- a think like a person or an
65+
event or a photo or a track.&nbsp; They are produced by different software
66+
modules, or apps.</p>
67+
<h3>Pane layout</h3>
68+
<p>Panes are rectangles -- HTML divs. They were originally designed to make
69+
the most powerful use possible of a large screen.&nbsp; </p>
70+
<h4>Large screen</h4>
71+
<p>In solid panes, when used with a lot of screen real estate, a pane starts
72+
at the top left corner of the space, and works downward, but isn't afraid
73+
of of using the whole screen. </p>
74+
<p>Panes do nest inside each other, but <strong>not</strong> like cute
75+
wooden window panes.&nbsp; An outer pane is free to put inner panes
76+
anywhere it likes to make sense and communicate well with the user. </p>
77+
<p>Panes should be tested on large screen sizes as well as medium and
78+
small.&nbsp; A user's journey might take them through some navigation
79+
steps to find after a while a picture, or map, or a chart, which really
80+
benefits from using up all the rest of the space.&nbsp; It can be very
81+
frustrating when you find such a resource, you have a large screen, but a
82+
developer at some point slapped a max width which suited their screen at
83+
the time.&nbsp; Don't let the push for mobile first leave the folks who
84+
delight in their huge screens facing a mobile-equivalents experience on
85+
them!</p>
86+
<h4>Small screen</h4>
87+
<p> On a small screen, by contrast, they should typically take the whole
88+
screen, but allow swipe navigation around a grid or a tree.&nbsp; There is
89+
(2018-11) no code, but some UI mockups have been done for the databrowser
90+
on mobile.&nbsp;&nbsp; The trick as ever is to re-use existing language
91+
the users will have come across where it exists and works. When looking
92+
for example at a attachment document in the materials of the meeting, you
93+
have to be able to vertically swipe through the pages of the document, so
94+
it is logical to horizontally swipe though the different documents, but to
95+
the left of the leftmost document instead a document being a navigation
96+
space at the top level of the meeting between between scheduling,
97+
location, attendees, program, materials, and notes.</p>
98+
<p>A challenge in Solid is that things link together and contain each other
99+
in a very free way. Whereas a Meeting App might have a nav-bar with the
100+
top level, [scheduling,location, attendees, program, materials, notes], in
101+
Solid the meeting may be a property of the person who you had the meeting
102+
with, and the nav bar be full things to do with the person. Not
103+
insuperable problems, but things to think about.</p>
104+
<p>&nbsp;&nbsp; While mobile first is an alternative in the works, the
105+
original "power user first" mantra.&nbsp;&nbsp; As it does so, it may
106+
invoke other panes to display things related to the main subject.</p>
107+
<h2>Edit anything - edit state </h2>
108+
<p>An attitude of the solid project has always been that collaboration
109+
between different people and groups is the goal. Therefore, wherever a
110+
user can view data they should be able, if authorized, to edit it too. To
111+
make it clear when this is possible, when it is happening, there are
112+
common colors for the different states of an input field</p>
113+
<table width="100%" border="1">
114+
<tbody>
115+
<tr>
116+
<td>Read, unedited</td>
117+
<td>Black on white</td>
118+
</tr>
119+
<tr>
120+
<td>Read, not editable</td>
121+
<td>Grey on white</td>
122+
</tr>
123+
<tr>
124+
<td>Edited, good syntax</td>
125+
<td>Green on white</td>
126+
</tr>
127+
<tr>
128+
<td>Edited, bad syntax</td>
129+
<td>Red on white</td>
130+
</tr>
131+
<tr>
132+
<td>Saving back</td>
133+
<td>Black on grey</td>
134+
</tr>
135+
<tr>
136+
<td>Error saving back</td>
137+
<td>Black on pink</td>
138+
</tr>
139+
<tr>
140+
<td>Saved back to the web</td>
141+
<td>Black on white</td>
142+
</tr>
143+
</tbody>
144+
</table>
145+
<p><br>
146+
</p>
147+
<p>Examples of this are the fields in the form system, and the source
148+
editing pane.&nbsp;&nbsp; The users should get used to any black on white
149+
data being in sync with the web of data, and the system should always make
150+
sure to indicate with the colors above when it is not the case.</p>
151+
<p>When there are network errors saving user data, never through the data
152+
away!</p>
153+
<h3>Link to anything: Identity</h3>
154+
<p>In Solid, you can store connections between anything any anything.&nbsp;
155+
This doesn't always make sense, and may not always be useful, but we do
156+
have to have a UI language which&nbsp; allows this.</p>
157+
<p>In a desktop environment, drag and drop is more or less ubiquitous.&nbsp;
158+
Anything can be dragged, and many things can be dropped on to.&nbsp; You
159+
can drag a person into a group to add them to a group. You can drag a
160+
person, or a group, or both, into the Sharing control&nbsp; to give them
161+
access to something, dragging them around between the different roles
162+
until they have the right form of access. You can drag things from outside
163+
the solid world into a solid: a desktop file into a solid solid folder to
164+
upload it; you can drag a URI from the URL bar icon of a browser into the
165+
solid world to connect in the thing you were looking in the browser.&nbsp;
166+
You can drag things out of the solid world .. for example if you drag some
167+
item in a complex databrowser display onto the tab bar of the browser just
168+
past the tabs, it will open a new tab viewing that specific thing.</p>
169+
<p>As anything is drag-able, it must be consistently clear what that thing
170+
is.&nbsp; One common widget used in many lists is a tree-part widget with
171+
an icon on the left, a&nbsp; label in the middle, and some control buttons
172+
("delete this", "visit this", ...)in the right hand part.</p>
173+
<p>The icon is ideally set to a specific image of the object, like a mugshot
174+
of the person or logo of a company or project, otherwise set to an icon
175+
for the class: a generic icon for a person, a group of people, a document,
176+
and so on.</p>
177+
<p>Where things are draggable in the desktop world, in the mobile world they
178+
need to have places to press on in various ways to capture their
179+
identity.&nbsp; The "Copy link" aka "Copy URI" functionality is very
180+
common UI language.&nbsp; Will the solid world be able to get away with
181+
just that, or will it need more "Mark this" where the marked thing is a
182+
second clipboard; or "Push this" to push things onto a stack?&nbsp; Should
183+
the things selected form an editable cache of interesting things which the
184+
user can pick from as the&nbsp; to all kinds of operations later? Should
185+
the user be able to scroll back through all the things they have every
186+
copied to the clipboard? Today's mobile clipboard is often not powerful
187+
enough, when you often need to copy the phone number and access code or
188+
flight number and reservation number at the same time.</p>
189+
<p>There is some design to be done here. </p>
190+
<h3>Button Color Language</h3>
191+
<p>We have tried to be consistent with colors:</p>
192+
<table width="100%" border="1">
193+
<tbody>
194+
<tr>
195+
<td>Green</td>
196+
<td>Add Data</td>
197+
</tr>
198+
<tr>
199+
<td>Red</td>
200+
<td>Remove Data</td>
201+
</tr>
202+
<tr>
203+
<td>Blue</td>
204+
<td>Commit, eg send a message</td>
205+
</tr>
206+
<tr>
207+
<td>Black &amp; White</td>
208+
<td>Change view, delete view</td>
209+
</tr>
210+
</tbody>
211+
</table>
212+
<br>
213+
<p>One inspiration was the Mac OS X contact view at the time, where a quite
214+
readable view of someone's contact details was annotated with little green
215+
pluses and little red minuses which made it clear where things could be
216+
changed and how to change them. </p>
217+
<p>The color language is that anything which does not add or delete data, or
218+
commit the user to something, is monochrome.&nbsp;&nbsp; We have resisted
219+
the temptation to us pretty colored icons -- even the Rainbow icon used
220+
for sharing.&nbsp;&nbsp;&nbsp; We may totally revisit this, and one day
221+
roll out a version with all the icons in really interesting colors
222+
representing the class of object or the domain in some way, but that is
223+
not the current language.&nbsp; We could also make it a user preference of
224+
course.</p>
225+
<p>The discipline of making the databrowser navigation of folders and lists
226+
and people and meetings be essentially monochrome has meant that resources
227+
like pictures and icons </p>
228+
<h3>Labels: use the ontology</h3>
229+
<p>The goal is of course to make everything as accessible as possible with
230+
people with different abilities, using different
231+
devices.&nbsp;&nbsp;&nbsp; The internationalization goals are most easily
232+
met by using icons rather than text.&nbsp; Some people, however in fact
233+
prefer text.</p>
234+
<p>The data in the system is RDF data, and in RDF, classes (like <em>Person</em>)
235+
and properties (like <em>friend</em>) have URIs.&nbsp; There are files
236+
out there on the web with information about them, which includes a
237+
human-readable label for the property.
238+
</p>
239+
<p>The labels are often in English, but on a good day, in many
240+
languages.&nbsp; This means that if the UI generates&nbsp; up its labels
241+
from the ontology you get potentially internationalization for free, if
242+
there are alternative languages available in the ontology.</p>
243+
<p>This has the benefit&nbsp; that it scales quite well, in that effort put
244+
into translating the ontologies, which can possibly be crowd-sourced, pays
245+
off as an immediate benefit for anyone </p>
246+
<table width="100%" border="1">
247+
<tbody>
248+
<tr>
249+
<td><em>Action</em></td>
250+
<td><em>Button label</em></td>
251+
</tr>
252+
<tr>
253+
<td>Create new instance of C</td>
254+
<td>&#10024;New (label(C))</td>
255+
</tr>
256+
<tr>
257+
<td>Create new thing related by property P</td>
258+
<td>"New" icon + label(P)</td>
259+
</tr>
260+
<tr>
261+
<td>Visit thing(s) related by P</td>
262+
<td>label(P)</td>
263+
</tr>
264+
</tbody>
265+
</table>
266+
<p>In general a good rule when coding to to to try to involve introducing
267+
any text for the user which would have to be translated.&nbsp; Use a
268+
combination of icons and text looked up in the ontology.</p>
269+
<p>Another idea is to make a composite icon out of the verb and the class,
270+
so "New Group" would be a compose icon of a small green plus (or star)
271+
superimposed on the icon for a group of people.&nbsp; This is quite common
272+
in desktop software, so the language will be understood.</p>
273+
<p>(Because you may want the ontology to be available offline, it may be a
274+
good idea to import a copy into code. How to do that is beyond the scope
275+
of this note)</p>
276+
<h3>Link to anything: Relationship</h3>
277+
<p>Demonstrating the relationship between two things typically involves a
278+
table with the relationship in the left and the object of it, or value, on
279+
the right. That <strong>labelled form field</strong> language is so
280+
ubiquitous in computer UI, we use all over.&nbsp; Having a user preference
281+
go flip it from left-right to right-left in locales where the user is
282+
reading everything right-left would be ideal.</p>
283+
<p>Relationships also show up in <strong>column labels for tables</strong>.&nbsp;
284+
Just the same language applies as for a form field label.<br>
285+
</p>
286+
<p>It is often easier to have a recognizable for icon for classes, like
287+
Person, Group, Adult, than for relationships like friend, child.&nbsp; So
288+
icons tend to less useful for expressing relationships than classes.
289+
However, when really there is only one main property linking thinks of
290+
class C to things of class D, then one use the icon for the class.&nbsp;
291+
If the only type of relationship a person can have an event, then the list
292+
of attendees can be given the person icon. </p>
293+
<h3>Link to anything; Potential relationship</h3>
294+
<p>More complex is the question of how to allow the user to see what
295+
potential relationships are available.&nbsp; As you drag in an object A to
296+
a drop target B, how do you know what relationship you are going to
297+
express?&nbsp; One way is for the drop zone mutate into a set of <strong>triage
298+
drop zones</strong>: Drop here to make this person and invitee, here an
299+
attendee, here an organizer.&nbsp; Another way is to just assume a default
300+
relationship, invitee, say, and then allow the user to edit that once they
301+
appear in the list.</p>
302+
<p>There are programs which do that -- but they are very bold about
303+
explaining to the user what is happening: large fonts in the labels.
304+
Fortunately the ugliness of the labels is temporary just until the user
305+
finishes the drop.</p>
306+
<p>The original tabulator code had a feature to allow any new data to be
307+
added to a form-like view, where the predicate was a pop-up choice of all
308+
the properties which logically were reasonable to use on the class of
309+
subject. Then the range of the property chosen would be looked up in the
310+
ontology, and the type of UI for the object of it would be selected from
311+
that.</p>
312+
<p>The same choice in fact occurs when you are editing a form, and you add a
313+
new field.</p>
314+
<p></p>
315+
<h3></h3>
316+
<h2>Making up panes: Widgets and Forms</h2>
317+
<p>Panes are the largest in the stack of UI systems.&nbsp; They are
318+
implemented in terms of lower level things. IN the case of the solid-panes
319+
solid-ui stack, the panes are implemented using widgets of various sizes ,
320+
and forms make out of widgets.</p>
321+
<p>A form is defined in the RDF data model. Typically a form is made by hand
322+
in Turtle, or it can be edited using the form-editing form.</p>
323+
<h3>To Be Continued</h3>
324+
<p><br>
325+
</p>
326+
</body>
327+
</html>

0 commit comments

Comments
 (0)