finally a bnode with a uri

Posts tagged with: ux

Data Web UX Challenges: Supporting different Roles

The challenge around offering the best tools for the task context.
Some hasty User Experience (UX) thoughts inspired by books I'm currently reading, and adapted to the Data Web context:

Despite a blurry separation between roles in software creation, there often is a personal tendency either towards Information Architecture and Business Analysis or towards Interaction and User Interface Design. In the Data Web space, tool developers and demonstrator creators still seem to be stronger in the former than the latter.

Now how do you get from here to there (where "there" equals more user-friendliness)? Maybe getting a better picture of the different roles your tool has to satisfy can help. As well as deciding on the target audience in case of an end-user-facing application. For example:
  • Data Providers: main focus is getting a schema and related data published without loss of quality.
  • Data Engineers: cares deeply about schema mappings.
  • Information Architects: agile schema change management.
  • Interaction Designer: simple APIs to integrate real data into highly customizable templates at the post-mockup stage.
  • Content and Data Editors: convenient editing tools.
  • ...

You should need less roles to describe the target user group for a particular application (or this is a sign that your focus may be too wide):
  • Curator: convenient editing tools.
  • Citizen: wants to be heard, wants browsing tools.
  • Data Journalists: want navigation and convenient extraction tools.
  • Data Analyst: comparisons and insight generation.
  • ...

For an end-user application, you can often narrow down the target audience and then create a highly tailored user experience. Less so for a tool. And it gets even harder when your tool implements a specification whose purpose is to broaden the reach of a technology. Like the Semantic Web and its younger relative Linked Data. They both want to simplify Knowledge Management to a level that it can work across the Web. The early adopters in this space range from AI pros to front-end enhancers.

I think it's worth spending the time to ensure the best possible experience for each of the roles you can identify for your app or tool. Even if this means that you have to create several tools that operate against the same source. Let's say you use RDFa or microdata in your HTML templates. You may then need separate visual access methods for Data Engineers and Interaction Designers. Similarly, you may please you product development team with a bespoke API, while the labs team appreciates a bleeding-edge SPARQL endpoint to explore new options.

Contextual configuration - Semantic Web development for visually minded webmasters

A short screencast demonstrating contextual configuration via widgets in semsol's RDF CMS.
Let's face it, building semantic web sites and apps is still far from easy. And to some extent, this is due to the configuration overhead. The RDF stack is built around declarative languages (for simplified integration at various levels), and as a consequence, configuration directives often end up in some form of declarative format, too. While fleshing out an RDF-powered website, you have to declare a ton of things. From namespace abbreviations to data sources and API endpoints, from vocabularies to identifier mappings, from queries to object templates, and what have you.

Sadly, many of these configurations are needed to style the user interface, and because of RDF's open world context, designers have to know much more about the data model and possible variations than usually necessary. Or webmasters have to deal with design work. Not ideal either. If we want to bring RDF to mainstream web developers, we have to simplify the creation of user-optimized apps. The value proposition of semantics in the context of information overload is pretty clear, and some form of data integration is becoming mandatory for any modern website. But the entry barrier caused by large and complicated configuration files (Fresnel anyone?) is still too high. How can we get from our powerful, largely generic systems to end-user-optimized apps? Or the other way round: How can we support frontend-oriented web development with our flexible tools and freely mashable data sets? (Let me quickly mention Drupal here, which is doing a great job at near-seamlessly integrating RDF. OK, back to the post.)

Enter RDF widgets. Widgets have obvious backend-related benefits like accessing, combining and re-purposing information from remote sources within a manageable code sandbox. But they can also greatly support frontend developers. They simplify page layouting and incremental site building with instant visual feedback (add a widget, test, add another one, re-arrange, etc.). And, more importantly in the RDF case, they can offer a way to iteratively configure a system with very little technical overhead. Configuration options could not only be scoped to the widget at hand, but also to the context where the widget is currently viewed. Let's say you are building an RDF browser and need resource templates for all kinds of items. With contextual configuration, you could simply browse the site and at any position in the ontology or navigation hierarchy, you would just open a configuration dialog and define a custom template, if needed. Such an approach could enable systems that worked out of the box (raw, but usable) and which could then be continually optimized, possibly even by site users.

A lot of "could" and "would" in the paragraphs above, and the idea may sound quite abstract without actually seeing it. To illustrate the point I'm trying to make I've prepared a short video (embedded below). It uses Semantic CrunchBase and Paggr Prospect (our new faceted browser builder) as an example use case for in-context configuration.

And if you are interested in using one of our solutions for your own projects, please get in touch!



Paggr Prospect (part 1)


Paggr Prospect (part 2)

Archives/Search

YYYY or YYYY/MM
No Posts found

Feeds