From 70d9d58e6bd444030e44ed7d03f2139c5cdae857 Mon Sep 17 00:00:00 2001 From: Michael Luggen Date: Sat, 17 Feb 2018 09:29:47 +0100 Subject: [PATCH 1/7] separation of roles clarifications --- README.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 3aa5a4a..d08ee1c 100644 --- a/README.md +++ b/README.md @@ -11,7 +11,10 @@ Thus the overall goal of this task force is to create a common specification for ## Goals - Leverage the RDF data structure -- Clear separation of roles regarding definitions (@fkleedorfer: not sure what that means - would appreciate more detailed explananation) +- Clear separation of roles regarding definitions + - Data Expert -> Selection of Data + - UX Specialist -> Creation of UI Concept (Mapping of the Graph) + - Designer -> Design of the UI - Enables an iterative development process - Highly reusable outcome (the transformations can be used in other contexts) - Handle language transparently From 38cfaed01c3ccc187d0caf65955975fdc625c4ed Mon Sep 17 00:00:00 2001 From: Michael Luggen Date: Sat, 17 Feb 2018 09:33:58 +0100 Subject: [PATCH 2/7] added timbls references --- README.md | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index d08ee1c..1277e87 100644 --- a/README.md +++ b/README.md @@ -48,13 +48,23 @@ As this is WIP, We'll clean this text up as we go along. However, right now, we * [papers](http://research.ld-r.org) * [website](http://ld-r.org/) +#### Tabulator +* [paper](https://pdfs.semanticscholar.org/fc88/f4d34e2a7e43fe8ffdb22dfcc2193a912c23.pdf?_ga=2.159102202.1111079707.1518835681-2059549870.1518835681) +* [paper](http://events.linkeddata.org/ldow2008/papers/11-berners-lee-hollenbach-tabulator-redux.pdf) + +#### solid ui +* https://github.com/linkeddata/mashlib +* https://github.com/linkeddata/solid-app-set +* https://github.com/linkeddata/solid-ui +* https://github.com/linkeddata/solid-ui/blob/master/src/widgets/index.js#L911 + ### papers * [Argo](http://ceur-ws.org/Vol-135/paper8.pdf) * [Customised Visualisations of Linked Open Data](http://ceur-ws.org/Vol-1947/paper03.pdf) ### ontologies * [shacl](https://www.w3.org/TR/shacl/) - +* [ui](http://www.w3.org/ns/ui#) ## Name of TF? - Human readeable RDF @@ -72,3 +82,9 @@ As this is WIP, We'll clean this text up as we go along. However, right now, we ## Use Cases [Adaptive GUI for Web of Needs](usecase_won.md) + + +Thanks! +timbl + + From 788244e70f10632414200fb3d2c0675bb1351f2c Mon Sep 17 00:00:00 2001 From: Michael Luggen Date: Sat, 17 Feb 2018 09:38:47 +0100 Subject: [PATCH 3/7] Update README.md --- README.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/README.md b/README.md index 1277e87..ddc10e6 100644 --- a/README.md +++ b/README.md @@ -84,7 +84,4 @@ As this is WIP, We'll clean this text up as we go along. However, right now, we [Adaptive GUI for Web of Needs](usecase_won.md) -Thanks! -timbl - From 861a334ae6a77a18d50c4dbc7745f4fdc4756de1 Mon Sep 17 00:00:00 2001 From: Florian Kleedorfer Date: Sun, 18 Feb 2018 13:10:39 +0100 Subject: [PATCH 4/7] Update usecase_won.md Add requirements --- usecase_won.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/usecase_won.md b/usecase_won.md index 81a1b39..488807e 100644 --- a/usecase_won.md +++ b/usecase_won.md @@ -28,5 +28,10 @@ Render a GUI from a priori unknown RDF, ideally in a way that fits the user's co Example: Show that the other user has confirmed my suggestion for an appointment in 3 minutes at location A +## Requirements for the UI Layer +### 1. Discovery of UI components +In WoN, you can post and find anything. The only thing you'll know about postings or messages a priori is that they are RDF datasets. They will have a few standard triples, but these don't normally interest users. Consequently, it is not feasible to prepare a UI library for authoring every conceivable WoN posting. Rather, we'd like a discovery system that finds the right UI component on the fly. For that to be possible, the components need to be adaptive in terms of visual style, language, context (whatever that is exactly - it is a thing). Moreover, the components must not pose a security risk in any way. + +### 2. Generic RDF authoring capabilities +For situations in which no GUI components can be found, generic tools are needed for content authoring. The requirements for those components are the same as in 1. In addition to that, the generic tools should allow non-RDF savvy Web users to author simple RDF structures. -(TBC) From c1c09b9b3b77cf1d92e3c5109c2245c5c380489c Mon Sep 17 00:00:00 2001 From: Ali Khalili Date: Mon, 19 Feb 2018 10:33:06 +0100 Subject: [PATCH 5/7] added Gitter badge to our repo it facilitates following the discussions! --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index ddc10e6..f1b527d 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,5 @@ + [![Gitter](https://badges.gitter.im/dev-1pr/1pr.svg)](https://gitter.im/rdfruit/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=body_badge) + # RDF Representation in User Interfaces Team **This is WIP!** From d9d348a01b420a45866c2031bd98825ecbfb48a1 Mon Sep 17 00:00:00 2001 From: Kevin Singer Date: Mon, 19 Feb 2018 15:47:37 +0100 Subject: [PATCH 6/7] # This is a combination of 2 commits. # This is the 1st commit message: More on won-requirements. # This is the commit message #2: Forgot to commit sthg. --- usecase_won.md | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/usecase_won.md b/usecase_won.md index 488807e..9678c97 100644 --- a/usecase_won.md +++ b/usecase_won.md @@ -7,31 +7,48 @@ Independent matchers find posts (=needs) that may be suitable for an interaction Users can then start communicating by exchanging messages that can contain arbitrary RDF. Thus, we have 4 main points where we'd like to use rdfruit: + ## 1. Create Posting + Generate arbitrary RDF, ideally using the perfect user friendly GUI. Example: I want to get from my current location to point B ## 2. Display a Posting when matched + Render a GUI from a priori unknown RDF, ideally in a way that fits the user's context Example: Someone is nearby and would drive me to B if I'm quick enough to hop on within 3 minutes. ## 3. Author a message + Generate arbitrary RDF, ideally using the perfect user friendly GUI. Example: confirm an appointment: in 3 minutes at location A ## 4. Display a message + Render a GUI from a priori unknown RDF, ideally in a way that fits the user's context Example: Show that the other user has confirmed my suggestion for an appointment in 3 minutes at location A ## Requirements for the UI Layer + ### 1. Discovery of UI components -In WoN, you can post and find anything. The only thing you'll know about postings or messages a priori is that they are RDF datasets. They will have a few standard triples, but these don't normally interest users. Consequently, it is not feasible to prepare a UI library for authoring every conceivable WoN posting. Rather, we'd like a discovery system that finds the right UI component on the fly. For that to be possible, the components need to be adaptive in terms of visual style, language, context (whatever that is exactly - it is a thing). Moreover, the components must not pose a security risk in any way. + +In WoN, you can post and find anything. The only thing you'll know about postings or messages a priori is that they are RDF datasets. They will have a few standard triples, but these don't normally interest users. Consequently, it is not feasible to prepare a UI library for authoring every conceivable WoN posting. Rather, we'd like a discovery system that finds the right UI component on the fly. For that to be possible, the components need to be adaptive in terms of visual style, language, context (whatever that is exactly - it is a thing). + +Moreover, the components must not pose a security risk in any way, e.g. component lookup shouldn't send sensible data like the user's location, passwords, etc. Also we should look into ways to support managing permissions for components to prevent access to and sending of sensitive data without the user's permission. ### 2. Generic RDF authoring capabilities + For situations in which no GUI components can be found, generic tools are needed for content authoring. The requirements for those components are the same as in 1. In addition to that, the generic tools should allow non-RDF savvy Web users to author simple RDF structures. +### 3. Consistent Style + +Applications using the system should still have a coherent visual style and adhere to typical user interface patterns to make the application more accessible and coherent with learned interface design language. A way forward here might be to split styling (e.g. color, border-radius, etc) from layouting (flex, grid, etc). Other alternatives could be parametrizing components with style variables or using a consistent style "API" (e.g. bootstrap or semui class-names, or even a different, intermediary language). This should allow instances of the framework to apply their own CI/skinning/look-and-feel without breaking the widget's layout. + +### 4. Mobile-First + +For the usual-reasons[^mobile internet usage constitute more than 50% of the overall usage and it's easier to move from a mobile design to a desktop version than the other way around] it should be possible to start on mobile plattforms. This means responsive components as well as being able to work with flaky and low-bandwidth connections (e.g. components can't be 1M each) \ No newline at end of file From d9f87d105c3a896ae45d53c7fb2ce6a2ed79340b Mon Sep 17 00:00:00 2001 From: Kevin Singer Date: Mon, 19 Feb 2018 16:13:17 +0100 Subject: [PATCH 7/7] More on won-requirements. --- usecase_won.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/usecase_won.md b/usecase_won.md index 9678c97..604fb26 100644 --- a/usecase_won.md +++ b/usecase_won.md @@ -10,7 +10,7 @@ Thus, we have 4 main points where we'd like to use rdfruit: ## 1. Create Posting -Generate arbitrary RDF, ideally using the perfect user friendly GUI. +Generate arbitrary RDF, ideally using the perfect user-friendly GUI. Example: I want to get from my current location to point B @@ -22,7 +22,7 @@ Example: Someone is nearby and would drive me to B if I'm quick enough to hop on ## 3. Author a message -Generate arbitrary RDF, ideally using the perfect user friendly GUI. +Generate arbitrary RDF, ideally using the perfect user-friendly GUI. Example: confirm an appointment: in 3 minutes at location A @@ -39,7 +39,7 @@ Example: Show that the other user has confirmed my suggestion for an appointment In WoN, you can post and find anything. The only thing you'll know about postings or messages a priori is that they are RDF datasets. They will have a few standard triples, but these don't normally interest users. Consequently, it is not feasible to prepare a UI library for authoring every conceivable WoN posting. Rather, we'd like a discovery system that finds the right UI component on the fly. For that to be possible, the components need to be adaptive in terms of visual style, language, context (whatever that is exactly - it is a thing). -Moreover, the components must not pose a security risk in any way, e.g. component lookup shouldn't send sensible data like the user's location, passwords, etc. Also we should look into ways to support managing permissions for components to prevent access to and sending of sensitive data without the user's permission. +Moreover, the components must not pose a security risk in any way, e.g. component lookup shouldn't send sensible data like the user's location, passwords, etc. Also, we should look into ways to support managing permissions for components to prevent access to and sending of sensitive data without the user's permission. ### 2. Generic RDF authoring capabilities @@ -51,4 +51,6 @@ Applications using the system should still have a coherent visual style and adhe ### 4. Mobile-First -For the usual-reasons[^mobile internet usage constitute more than 50% of the overall usage and it's easier to move from a mobile design to a desktop version than the other way around] it should be possible to start on mobile plattforms. This means responsive components as well as being able to work with flaky and low-bandwidth connections (e.g. components can't be 1M each) \ No newline at end of file +For the usual-reasons[1](#user-content-fn1) it should be possible to start on mobile platforms. This means responsive components as well as being able to work with flaky and low-bandwidth connections (e.g. components can't be 1M each) + +[1]: mobile internet usage constitute more than 50% of the overall usage and it's easier to move from a mobile design to a desktop version than the other way around