Re: UI/UX snippets

Hi Bart. Thanks for the link to EnyoJS, and for the reminder of how 
complex a language for UX design can be.

Thinking of SHACL as primarily a validation language, but one that could 
have a useful interaction with something like Enyo or other UX design 
packages, what do you see as the key properties that SHACL must have to 
make that connection?

kc

On 11/12/15 1:38 PM, Bart van Leeuwen wrote:
> Hi Ted,
>
> I have been on this for about 7 years already,
> I've looked at Fresnel [1] but at the time it was a dead-end, I didn't
> like the fixed connection between the data and the lens.
> What I wanted to have is a way to express my own layout and ordering of
> data I receive.
>
> In that sense Shapes as a concept is actually that what I was looking
> for. Not so much to auto generate user interfaces but to select which
> user interface parts to use for certain types of data.
>
> Last year at ISWC I presented a approach [2] in the developer workshop
> [3] which actually mentions this working group.
> In the mean time I was able to deploy this concept in more than 60 fire
> station world wide and use it as a frontend for the Firebrary [4] (
> sorry text is all Dutch now )
>
> The UI is defined by json structures ,'shapes' if you like, which fairly
> easily could be converted to JSON-LD to include shapes vocabulary.
> Currently the 'shapes' selection is done primarily on the RDF class and
> the constraints are very limited and processed in javascript.
> The nice part is that you actually define which properties go where on
> your user interface at user interface level.
>
> I'm currently awaiting a new release of EnyoJS which would make playing
> with the code a lot easier, the next step would be to open up the source
> code so others can play with this.
>
> I'm not 100% sure it relevant to the working group, but at least your
> email triggered me to write this down :)
>
> [1] http://www.w3.org/2005/04/fresnel-info/
> [2]
> http://blog.resc.info/using-interface-encapsulation-to-listen-to-linked-data-predicates/
>
> [3] http://iswc2014.semdev.org/program/
> [4] http://www.firebrary.com/data/terms/nl/lmc/1.2/200000006
>
> Met Vriendelijke Groet / With Kind Regards
> Bart van Leeuwen
>
> ##############################################################
> # twitter: @semanticfire
> # netage.nl
> # http://netage.nl <http://netage.nl/>
> # M.A. Reinaldaweg 79
> # 3461AJ Linschoten
> # tel. +31(0)6-53182997
> ##############################################################
>
>
>
> From: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
> To: public-data-shapes-wg@w3.org
> Date: 12-11-2015 21:42
> Subject: UI/UX snippets
> ------------------------------------------------------------------------
>
>
>
> Towards the UI/UX aspect of things --
>
> The following might be considered Use Case, might feed more
> directly into Requirements, or might be incorporated (no doubt
> with substantial rewording) directly into the spec.
>
> When collecting data (which should conform to a shape), this
> is often done via forms, which might be green-screen character-
> based terminal interface, full GUI, or somewhere in between.
>
> Automated generation of such a form is often desirable.
>
> So...  describing an entity, we know it has some attributes or
> properties, each of which is identified by an IRI, which is
> generally not very human friendly.
>
> Associating an rdfs:label with that property gives a "human
> friendly version of the IRI" -- so, for instance, foaf:name
> gets a nice label of "Name" -- which could be displayed
> alongside the text entry field (which the tool knows will
> receive a string, because that's the range of foaf:name).
>
> An rdfs:comment might give a somewhat more fleshed out version,
> such as, "the person's full name" or "the full name to be used
> for this person", which might be displayed as mouse-over help text.
>
> A dcterms:description might give a much more detailed version,
> which might be displayed upon a click, in a pop-up window, a new
> browser tab/window, etc.
>
> There might be some further attributes, possibly listing all
> possible values for the property -- which a UI generator might
> use to create a selection menu for a long list (whether there
> was to be one selection or many), or a group of radio buttons
> for a short list with a single selection, or a group of check
> boxes for a short list with multi-selcetion...
>
> This is not exhaustive, by any means.  One of the things we might
> want to do with our next PWD is to call for pointers to UI/UX
> ontologies that we might link to -- because reinventing the wheel
> is not good, and UI/UX is a huge space, but having some simple
> hooks to other people's work can benefit us all.
>
> I hope that's helpful to the process.
>
> Ted
>
>
>
>
>
>
> --
> A: Yes. http://www.idallen.com/topposting.html
> | Q: Are you sure?
> | | A: Because it reverses the logical flow of conversation.
> | | | Q: Why is top posting frowned upon?
>
> Ted Thibodeau, Jr.           //           voice +1-781-273-0900 x32
> Senior Support & Evangelism  // mailto:tthibodeau@openlinksw.com
>          // http://twitter.com/TallTed
> OpenLink Software, Inc.      // http://www.openlinksw.com/
>          10 Burlington Mall Road, Suite 265, Burlington MA 01803
>      Weblog   -- http://www.openlinksw.com/blogs/
>      LinkedIn -- http://www.linkedin.com/company/openlink-software/
>      Twitter  -- http://twitter.com/OpenLink
>      Google+  -- http://plus.google.com/100570109519069333827/
>      Facebook -- http://www.facebook.com/OpenLinkSoftware
> Universal Data Access, Integration, and Management Technology Providers
>
>
>
>
>
>
>
>
>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Friday, 13 November 2015 01:02:24 UTC