How to Maintain a Prototyping Mindset When Building for the Semantic Web

I recently gave a lightning, 15 min. talk, as part of Reddit’s “Web Devign Talks.” The talk covered the importance of keeping a prototyping mindset in all aspects of our web design and development practice, with reference to the idea of the semantic web. This is an overview and reflection of that talk.

We should semantically structure our web content early in a design process and, to put it in a funny way, embrace accessibility for not only humans, but also machines.

https://www.youtube.com/watch?v=dQopI3QZP4A

You can scan the contents in the following text. For better experience with accompanying slides I recommend to watch the video. Also, you can find some more explanations in the "Questions and Answers" section at the end of this page.

A prototyping mindset

Applying a prototyping mindset through a perspective of the semantic web, opens up an ocean of new possibilities for all of us. It’s the source of inspiration that can enhance our creative potential, so we end up with better content, that is more structured, better information architecture, user experience and all of this can make us at the end be more productive in general.

We’ve been designing for static mediums for ages. And the web has changed all of that. It’s a medium that is highly dynamic and unpredictable.

The challenge of web design is to communicate an idea or concept that we want to share with the world:

• through a dynamic content
• on different kinds of displays and output devices
• to different kinds of visitors

This simply means that we have to take many things and technologies into consideration from the start of a project, and it’s a huge burden.

Now, in our workflows, what’s currently a mainstream, to design for all this complexity we moved from linear waterfall processes being more lean and agile. We use powerful tools such as Figma, Sketch, XD and similar. There, we create various simulations for our projects in forms of mockups, wireframes, prototypes of various fidelities. We are also building modular systems of components, and we can in general feel that we are pretty much advanced with our processes.

However, some people see the problem is, no matter how advanced our design tools, what we end up with are purely static images. Yes, we can click on them and move around, but they are still just static images. Matthias Ott calls this our "Illusion of Control". He puts an idea that We should explore the materials of the Web to work out their characteristics which then shape the design patterns of our system, and that the best tool we have for that, so far, is prototyping. But what kind of prototyping? The prototyping that uses web ingredients. That uses the web itself as the material to build with. He describe this idea the following way:

For physical products, certain technical and aesthetic qualities like structure, surface, flexibility, or durability characterize the nature of a material. For digital products, similar qualities can be explored: How flexible is a solution? How robust is it? How well does a solution work in different contexts? How much interactivity does it have? Does it allow growth? How performant is a certain framework, how flexible a CSS methodology and so on. To assess all those qualities we need a tool that is just as approachable, just as flexible, and just as extendable as the Web itself. This tool is prototyping.

Put it simply, the goal is to come up with a functional prototype in order to test and validate our assumptions as early as possible, assuming that even the best of us could do it a lot wrong during the design process. That could be possible advice on how to deal with this complexity of the web medium, and why the prototyping mindset would be important to keep in our practice.

The Semantic Web

But designing for humans doesn’t make the complete image of a web landscape. Not only humans, but also machines become users of the web and they are going to become our customers anytime soon. They will consume our content through a semantic understanding.

In the era of Internet of Things and semantically rich websites, let me put a quick example, our smart refrigerators would know how to buy food for us, online. I’d say for example that I want to prepare some italian dish this evening and it would check if I have all necessary ingredients, and if not it would order it for me from the internet.

So, We'll want to design these experiences for machines, because just like humans, they are in need, and become able to, more and more, understand our published web content.

And we have a name for this kind of web where content is meaningful to both humans and machines. It’s a Semantic Web. Sir, Tim Berns Lee, the creator of the World Wide Web coined the term, himself, a long time ago.

We realized that we have to address the needs of disabled people and make our websites accessible. We realized that we have to be inclusive. Now, on the other side of the spectrum, we have an equivalent demand, not to discriminate and make the content accessible to machines.

And the good thing is that this part of making a semantic understanding of our content is in our control, we have at our disposal semantic vocabularies/dictionaries that we can implement in the form of structured data to talk to machines about our Products, Services, Events, Articles, and we have a chance to include it in our design process.

So, having in mind the current progress and the evolution of related technologies and a global infrastructure, It’s a good timing now to bring more awareness about these topics.

Frederick O'Brien makes a strong call to our community. He says:

I put it to you that structured data is a really, really important factor to understand and implement in the coming years. It doesn’t just improve your chances of ranking highly for relevant queries. More importantly, it helps make your websites better — opening it up to all sorts of useful web experiences.

In all its beauty, this adds even more complexity to an already complex landscape. And the answer again could be a prototyping mindset.

Momentum

With all mentioned above, I would like to introduce you to a new idea. We call it Momentum.

It could be described as an environment. So I would like to put a few perspectives on what kind of environment it is.

It’s an environment for prototyping, using materials of the web. The most fundamental material of the web, as we know, is HTML. But there is a lot more when it comes to it. Here, we talk about a new kind of prototyping that involves HTML along with:

• semantic dictionaries

• dynamic data modeling

• inclusive design patterns

• content design system based on information quantity.

  
  

The idea is to put GUIs over all these aspects. In this way, as you can imagine, we would drastically broaden the range of available designing decisions. Because, many things that are considered part of development are put right into the hands of a designer through a GUI. And if we are developers it means that we could do more stuff with less effort.

On top of that, imagine there we have a completely open css and js editors, so we can write custom styling and interactions there, and freedom to use css preprocessors, or to integrate our favourite frameworks. Imagine it as Codepen, except the HTML part is automated and composed in a completely visual manner through various GUIs.

There are dozens of perspectives to describe what this kind of environment is and what it could offer. Let me just put a few of them:

• It’s an environment that could help us enhance our information architecture practice.
• It’s an environment that would let us quickly test and validate our designing decisions.
• Consider it as a highly modular LEGO set, made of graph db, that works in sync with semantic dictionaries and modular, frontend CMS, all controlled via a UI.

It's a software that sits next to a content and unlocks a new level of web workflows.

Join in

With this in mind I would like to invite you to join me in the upcoming series of discussions on Exploring Alternative Web Workflows. During the course of the series we will build a small website project from scratch. I will show you the exact semantics-first design process and thinking in semantics early on in the process of content structuring.

In Session 1, we will define the scenario and requirements of the project, potential user stories and we are going to write some html code to prototype content model entities and demonstrate the problems related to current prototyping workflows.

In Session 2, we will dissect a piece of HTML artifact that we’ve got from session 1, and will use it to come up with the concepts that make fundamental building blocks of Momentum environment.

In Session 3, I’ll demonstrate a proof of concept and show how this kind of environment unlocks new level of workflows and enables us to switch our design mindset and think in different contexts.

So, a lot of adventures and experiments from the lab in front of us, and yeah , feel free to join, of course.

To get notified about the schedule of the upcoming sessions subscribe at themomentum.io.

Questions and Answers

Here are some of the questions that were asked by the audience during the talk session.

How much time should I spend prototyping?

This is a great question. It points directly to problems related to the prototyping mindset itself. I mentioned that the idea is to develop and keep the prototyping mindset in all aspects of our practice. However the gap between the prototype and the final product, may appear as the trouble, Be it HTML that remains static itself, or conditional and interactive logic that is threatened to become spaghetti, or CSS that lacks a structure. So you may find it contradictory to keep the prototyping mindset, and still not end up being “dirty”.

These problems are intended to be listed at the conclusions of Session 1 of the upcoming series that I announced, and these problems are exactly to what Momentum gives a solid part of an answer. Momentum is intended to bridge this gap and enable us to keep our prototyping mindset even deeply in a production mode. Session 2 of the series will uncover concepts that allow this to happen.

I can give a few hints in advance:

• In terms of HTML and dynamic data modeling, Momentum makes the infrastructure that is automated, immediately LIVE, and controllable via UI.
• In terms of CSS it gives out-of-the-box semantic structure as the “kind of framework”, that is related directly to a semantic data model. This way CSS code is kept highly organized by default.
• In terms of JS, as the automated HTML infrastructure gets a huge burden off of JS, we are left with simplicity to use JS for lightweight logic and add only the chunks that are necessary for the interactions with the page. This refers to what I pointed out that we exaggerate with the usage of JS and the current trends to put everything we build into it. And this is where I propose to get back to roots, where semantics of HTML in multi-page applications plays a central role.

Do you use the prototype for production code, or do you throw it away and start programming from scratch for production?

The art of engineering and getting complex products to the world lies exactly at this point, to keep the balance between these 2 aspects: “something that just works” and a “stable version”. There is no exact recipe.

Momentum tends to bridge this gap, to allow us to be in production while still applying a prototyping mindset.

What are the main concepts that differ when designing for machines rather than humans?

Humans consume content visually through screens, or by sound (as for now). Machines are supposed to consume content through a semantic understanding. In this sense, designing for humans is related to concepts such as content-first, mobile-first responsive design, semantic html that we assume is accessible. So, accessibility-first applies here to. But let’s stop for the second and think of what we are actually doing when making our websites be accessible through screen readers? Among other things, we actually apply techniques that allow this device (could it be also considered a machine?) to read the content of our pages. We do this mainly through HTML, using the native HTML components whenever possible, considering the  semantics of individual tags, and using the available HTML attributes (WAI-ARIA). If we make this practice the central role and give it a first place in our process (we can call it accessibility-first), we can say that we are designing for disabled humans, right?

In this context, designing for machines is not a different kind of practice. The difference is only in the HTML attributes that we’ll apply. For example, we may use microdata annotation, that is actually a part of HTML5 specification. These 3 attributes do the magic: itemscope, itemtype and itemprop. Applying these attributes to our HTML would mean that we have a fully semantic HTML, enhanced with “semantic understanding” through which smart machines can consume our data.

What I am actually proposing is a semantics-first approach. In the same manner as we’d put accessibility to the first place in our design process, we should put the complete semantics of our HTML to the first place in the design process, too.

It’s actually a very simple idea that should be easily understood by people who do accessibility. The problem is that doing all of this manually makes a huge burden and additional costs to our projects. Momentum addresses exactly this problem. It allows playing with HTML as with the modular LEGO set that is enhanced by automated semantic annotations. I will uncover this concept in depth in Session 2 of the series.

Are you not still designing for humans who design, develop, and enable those machines to take actions on our behalf?

The idea is that we, humans, control the behaviours of machines, and delegate our search needs to these smart devices. Imagine, for example, a car that is smart. A human could have  the following “conversation” with it: “Hey car, when you need maintenance, just go and do it yourself. I don’t want to bother searching for best options, you (a car) should do it yourself and just present me with the best options (best car garages, that provide best maintenance services, by best reviews, optimal prices, and so on…), and I (human) will pick the best out of these results and give you a permission to go yourself there and pay for your maintenance. And don’t forget to get back home 😉”. You can feel in this example how much “search burden” should be put off of us, humans.

So, by applying semantics in our HTML, we are actually giving this car a possibility, “an interface” so to say, to interact with available public data. And what is this public data? Exactly the websites that we design and publish that are semantically annotated. In the upcoming future it could make a huge difference if I make the website for my client (that is a garage, and car maintenance provider) semantically rich (semantically annotated), and if Ron doesn’t. Because that imaginary car would come exactly to my client, because it could “read” the content from my clients’ website through a semantic annotation. Ron’s client would stay “in the darkness”, invisible to the car. Sorry Ron, and sorry for your client.

What is structured data and who determines if it's structured?

Can you guess how simple and familiar the answer to this question is? Let’s take IBM’s definition:

Structured data — typically categorized as quantitative data — is highly organized and easily decipherable by machine learning algorithms. Developed by IBM in 1974, structured query language (SQL) is the programming language used to manage structured data. By using a relational (SQL) database, business users can quickly input, search and manipulate structured data.

Now, in terms of the Semantic Web, structured data is considered the content that is annotated by publicly available semantic dictionaries. There are numbers of public, semantic dictionaries. The most popular and robust one is schema.org.

To make it structured, the content could be annotated through: RDF, microdata or JSON-LD. Microdata is part of the HTML5 standard, based on HTML attributes and closest by the concept to people who work with accessibility in mind.

Frederick O’Brian explains structured data in his article “Baking structured data into your design process” as:

Structured data is a way of labeling content on web pages. Using vocabulary from Schema.org, it removes much of the ambiguity from SEO. Instead of trusting the likes of Google, Bing, Baidu, and DuckDuckGo to work out what your content is about, you tell them. It’s the difference between a search engine guessing what a page is about and knowing for sure.