- So, hi, everybody.
I'm Lea.
Before I start, here's a little known fact about me, I'm originally from Greece and specifically, from the island of Lesbos, this is where I grew up which technically makes me geographically lesbian.
Have you ever met anybody else that can claim this? So, my journey in coding actually began almost 20 years ago in 1998 with Visual Basic 6.
It's a little embarrassing, but hey, there are worse things a 12-year-old could be doing.
And I only discovered web development much later. In 2005, actually, through a forum we made with a friend of mine, this is a screenshot I found from it from 2008, and of course, it's in Greek, it was a Greek forum, so...
That was using a software called vBulletin which was written in PHP, it was not open source, but it was visible source, and for me, this experience was mind-blowing. After having spent seven years, coding with nobody using the apps I was making, the only motivation I had was that if I made something good enough, somebody at some point would use it, like it would somehow magically get users.
I mean, if I made a good app, the skies would open and users would fall somehow.
And suddenly, I had something that I could upload something via FTP because that's how things worked back then and people would use it immediately, and I was like, this is amazing, more people should be able to do this. I should make this easier, I should do whatever I can to improve this, this process, make it easier. So, when I started, I was also learning PHP and then JavaScript and then CSS and along all three, sort of picking up HTML as I went.
So, the first thing I ever contributed to the community was actually bulletin boards.
Nobody had heard of me back then, so you probably don't know about this, but this is how I started contributing code, it was via vBulletin mods.
There was a community that you could post modifications you made to the source code of vBulletin and it was not open source, so you could actually not see the code that other people had posted, unless you registered and proved you had a valid licence, like way different than how things are right now.
But it got me started and as I was learning these technologies, I was discovering these little tricks or I was writing some reusable pieces of code that I thought, hey, maybe I should share this with other people, maybe it would be useful to someone else, maybe it would help them do their work easier, so I started a blog in 2009 and I started posting about all these things I was making.
And this led to a lot of open source projects. I say 2009 here, but I wasn't posting them on GitHub back then, I started posting them on GitHub I think 2010,2011.
But even then, I was thinking, is there any way I could actually improve the technology itself, would that even be possible.
Sure, I'm posting these open source projects that use these technologies to create abstractions, but what if I could actually improve the technologies, would standards be the answer? So, in 2012 I joined W3C as a staff member and the CSS working group, I left W3C in 2013, but I stayed in the CSS working group as an invited expert. So, the thing about standards is, the way standards seem from the outside was kind of like this, like, we tend to think that people in standards are creating huge features all the time and now there's light and now there's like flex box and you know, creating all these features, but actually, the reality is a little more contrived.
This is the thread in the CSS working group GitHub repo with the most answers and it's about commas and the colour function.
This is the thread with the most comments and it's about commas, and it goes and goes and goes and goes. Most discussions are about either naming which we call dike shedding 'cause it can end up going on for ages and ages, everybody has an opinion about names or commas and things like that.
Or like, tiny, tiny edge cases and how they interact with each other.
So, it wasn't exactly what I was looking for, but I stayed because it's still very rewarding, you reach a lot of people and even if you make a little difference in their lives, it's still a lot of people that you can reach.
So, it is rewarding, but I kept looking on how could I improve things.
I wrote a book along the way, maybe the way to improve things was to use the technologies better instead of changing the technologies themselves. But I kept looking.
And in 2014 I thought maybe academia has the answer. I mean, there's a lot of cool stuff that came out of academic research.
Later I discovered that a lot of the stuff that's invented in academia stays in academia, but still, there's a lot of stuff that came out of it.
So, hey, maybe this is the answer, so I apply to MIT for a PhD, I got accepted and I moved to Boston and I joined the Haystack group, this is our recently redesigned webpage.
So, the Haystack group does research in HCI which is the academic term for usability, it starts for human-computer interaction.
Or I guess you could call it the fancy academic term for UX.
It's led by this guy who's pretty much one of the coolest people I've ever worked with, he's not a developer, he's a computer scientist, like a 100%, but throughout his career, he's been trying to improve the way that people manage information, publish on the web. He started from completely different areas in computer science, published really cool research and then moved to other areas and published cool research. Most academics are too scared to do that, they just stay in the same area their entire lives and he's changed like four areas.
And what I like is that he deeply cares about improving the web.
It's not, many academics are like, how many papers can we publish in a year? He's not like that, so it's great to work there, and in general, so far, I've been at MIT for three years and I'm quite enjoying it, I basically get to work on whatever I want and get paid for it and publish it as open source, it's pretty cool.
So, both me and David, our views were very aligned in a certain thing, a certain problem that we saw. So, many people start learning web development by learning HTLM, CSS, and they're experimenting and refreshing the page and seeing what they've done, and it's all good, and it's exciting, they get feedback and then at some point they want to go beyond the simple static page, maybe they want to add some editing, maybe they want to add some persistence, you know, it's everyday things we use on other websites, it makes sense that soon enough somebody learning web design, web development would want to implement something like this.
And once they want to go this one step further, they're suddenly bombarded with all this software engineering terminology and all these technologies they have to learn and build systems to instal, and it's frustrating.
It should be easier.
There are so many technologies that come out every day and it seems that instead of making the landscape easier, they are making things harder.
They are making most people as frustrated as this baby. It's very indicative, so there's this website called todomvc which compares multiple JavaScript frameworks and how they implement the same to-do list. The to-do list they implement is shown here. We counted how many lines of JavaScript code were needed to make this simple to-do list with each of those frameworks and you can see the results here.
We're talking about a basic to-do list, the most basic example of a data-driven application.
If you think about editing data, and storing data, the to-do list is probably the simplest thing you can come up with and it's still in the hundreds.
And you might be thinking what do lines of code matter? It's not like cherries that you get by the kilo, so what if it's 400? Maybe it's 400 easier lines of code than, I don't know, vanilla JavaScript which would be a few hundred as well possibly.
The thing is, when we are developers, we tend to think that everybody is the same and that everybody lives in the same bubble, but actually, there are many people even in our community that find JavaScript difficult and struggle with it.
At some point I asked, yes, this is pretty much as far as you can get from scientific data, this is a Twitter poll, I'm very aware, but I'm not aware of any proper data of this, so this is all I have.
And it's 3,600 votes, so it is a lot of data, and I asked, hey people who write HTML and CSS, how comfortable are you with JavaScript? And it turns out that only half are very comfortable. The rest are somewhat struggling, and one in five is not comfortable, so for those people, yes, every extra line of JavaScript is a struggle. It seems that today this is pretty much the state of web development in terms of abstraction. On one side, you have vanilla JS and JavaScript frameworks that make things a little simpler, but still not enough and on that side you get more control, you can make everything you want, and there are new APIs every day giving you even more power, but also, you basically need to become a software engineer to do them.
And on the other side, you have prefabricated software like the vBulletin I started with, that is something I would consider on that other end of the spectrum, like things you instal and configure, CMSs, WordPress, those kinds of things, but what is in the middle? There doesn't seem to be anything.
And you might be thinking, or at least many of you, I write JavaScript, I'm comfortable with JavaScript, why should I care? Before you tune out, let me make this point. The thing is, yes, you are able to write the JavaScript, but if we make web programming more accessible to novices, then it's more accessible to everybody, including developers.
Think about when sliders were added to HTML5 or native date pickers, it's not just web designers that use them, developers use them as well because it's easier.
And you might be thinking, okay, but why should we focus on developers? I mean, it's developers that create on the web, right? Primarily, why should we even care about novices? So, we talked with a lot of people and it turns out that regardless of skill level, there is one thing that is constant, the desire to create.
Everybody we asked had ideas about things they wanted to create, the only thing that differed was whether they thought they could make it.
So, I think it's quite important to try and empower these people, to create their ideas and also make things easier for developers alongside. I'm not so much interested in making a technology that is a stepping stone for learning real programming, I'm more interested in making real programming easier. So, the research question we explored is can non-programmers create web applications and for that we made MAVO which is a language, it's a language that's based on HTML. And you might be thinking, why base it on HTML, why not base it on something else? HTML actually has a lot of benefits, I think it's probably the most successfully structured language out there.
There are so many people with very low technical skill that can write a little HTML.
The reason for that is that it's very forgiving, if you make a mistake, it even tries to fix it for you. Arguably, with not always very good results, but at least it tries and even when it can't, it fails gracefully, compared that with JavaScript where a missing closing parentheses can completely destroy your app.
You might end up getting a blank page.
Also, its syntax is relatively small and I'm not talking about the spec here, I'm talking about the syntax you have to learn and store in your head.
Once you've learned how tags work and how attributes work, that is it, you can basically read any HTML document almost.
All you have to learn now is what elements exist, and what attributes exist, but the syntax, you've pretty much learned it already, you can learn it in an hour or less.
And also it's portable, that applies to pretty much most web languages, but it doesn't apply to systems where languages are tied to specific system and specific company and if the company goes down, then the entire thing goes down as well, like Java for instance. And we focused on a class of applications we called CRUD and lightweight computation. CRUD is an acronym that means create, read, updated, delete, and it basically describes data-driven applications. Pretty much most applications we use on the web are data-driven apps, even Facebook is basically an app around data.
And the primitives we decided to address, we figured the ones that are needed the most are editing, being able to edit the data.
When you learn HTML and CSS, you can create static websites, but you cannot really edit them and store the results.
So, editing and persistence are two big ones, also the collections, when you want to have multiples of something, for example, a blog is a collection of blog posts, each of them containing a collection of comments. Collections are pretty much everywhere on the web. Uploads, it seems to require a lot of effort to just be able to upload an image from a static website, it should be much easier, or any type of file, and data flow, let's say I have a slider here and I want to reflect its value somewhere else, maybe do some math on it. By the way, Mavo is implemented currently as a JavaScript library and a CSS library, so basically including these two files in your page lets you experiment with the language.
And before I go into the syntax, here's a little overview, an example, this is a to-do list made with Mavo, as you can see, you can add things, you can delete things, you can drag and drop, rearrange them, shows you how many are done, how many in total.
So, how many lines of JavaScript do you think someone had to write to make this to-do list with Mavo? Yeah, zero.
This is everything someone needed to write to create this to-do app.
Well, and some CSS for styling, and actually the highlighted bits are stuff we had to add for Mavo, and in fact, the property attribute is not even Mavo-specific, it comes from the sort of forgotten spec that nobody really uses called Dardfa.
So, we sort of reused it for Mavo.
And let's dive into the syntax a bit.
To activate Mavo in a certain region of the page, one uses the mv-app attribute, with a name for the app, similar to an id.
In fact, if you have an id, you don't even need a value. You can see what happens here, there is nothing to see here, so all that appears is a bar that's kind of useless at this point which you can hide with mv bar equals to none. But for the next few examples we're not gonna do that because when you're learning, it's useful for it to be there.
And of course, if we didn't have an id, we could just do that, same result.
And you can also customise the bar, remove any styles, but right now it's not super-relevant. The first thing that's quite cool is how you do persistence, how you specify where your data is stored.
All it takes is one attribute.
If you want to store your data locally in the browser, you just give mv storage the value local.
But it doesn't stop there.
You can use a GitHub URL as the value, and then your data is stored on GitHub and Mavo takes care of authentication.
Or you could give it a Dropbox shared URL as the value and then your data is stored in Dropbox and you're also presented with authentication. There's an API for people who can write JavaScript to extend what back-ends are available, and for people who do write JavaScript it's very easy to write a plugin that adds an additional back-end.
But out of the box, GitHub and Dropbox are supported, also locally, and also storing in another HTML element which could be useful for debugging or for combining with other libraries.
So, you can see how the authentication works there, it's basically the same to-do app, except it uses GitHub for storage instead of the browser.
So, you might be wondering, okay, so I've specified where my data is stored, but what is actually stored? So, you specify what will be stored by using the property attribute and you have to give it a name as well, so in this case, we've applied the property attribute on two elements and then put a slider and if I can change it, I can change the value here, I can move the slider and you can see that this indicates that we've changed the data since we last saved, and I can click here to save.
And if I refresh the page, I guess I could do this to refresh, you can see that the values have persisted. Of course, if all you want is to auto-save a form, it's kind of annoying for people to have to click save, so you could enable auto-save.
And by default, it's maximum every three seconds, let's see how that works.
So, if I move the slider, it still shows me that I have unsaved changes, except after three seconds it goes away because it's saved.
And if I refresh, you can see that the change persisted even though I didn't click save.
But I could also give it a value of zero then the save button disappears entirely because my changes are persistent immediately and that's quite useful for things like comment forms for instance where you want to persist the data. It doesn't have to be an entire application, it can be as simple as a comment form on a blog where you want to save a user's draught.
And you might be wondering, okay, for forms it's kind of obvious how you change the data, but what happens if I add a property attribute on any random HTML element? So, Mavo has specific rules on how to edit different types of elements, which are of course extensible and you can see here how each of those types of elements becomes editable.
For images, you could change the source of the image and if you're using a remote back-end for storage, you could also upload images just by using an image automatically, you don't have to do anything to enable uploads, we'll see this in a bit. For the H2, it just became editable in line on the page, because I'm using a time element for the date, I get a date picker.
And for the metre element, I can just move my mouse over it and click.
And of course, all of this is customizable. So, here we have a list of hobbies with just one hobby, and we can edit it, but we can't really do much, we can't add more hobbies.
But what if we want to list more of them? Of course, we could multiple the property itself. Interesting, yeah, I think I had saved data there before, that's why.
We could multiply the property itself, but still, what if we want to delete one or add more? One thing we could do is, there's an attribute called mv multiple which is pretty much one of my favourite parts of Mavo and many people's favourite parts which basically turns any element into a collection with controls to add items, delete items, notice that now I added an item by hitting enter.
All keyboard shortcuts are just there by default. I can delete an item, I can undo the deletion. And on elements with more properties, more complex elements, I also get a drag handle, on simpler lists I can just drag and drop each item. And like I said, you can have more complicated lists of items.
For example, this is our sort of cat home page example from before, and let's turn this into a collection. And as you can see, now I can add another cat. And pretty much as many as I want.
And of course, I could nest collections as well. What if instead of a cuteness field I had a hobbies field? With something like that.
Oh, I forgot mv multiple here.
And you can see how it works.
And who has this hobby, but whatever.
So, you can see how it works and by just annotating an existing static HTML with these attributes, I can actually end up creating really complex schemas that if we were actually doing them the proper way, with databases or existing technologies, it would actually take a lot of knowledge about how data works.
But with Mavo, you can just annotate an existing HTML page and make it editable and storable. Here is a demo, using Mavo to edit a simple homepage and actually it's using a TinyMCE plugin, how many of you have heard about TinyMCE? Most of you, okay, so I don't need to explain what it is, it's for rich text editing on the web.
There's a plugin for TinyMCE that enables a Mavo property to be edited via TinyMCE if you want to have rich text, which, let's face it, in most websites that you need to edit, you do need to have areas like this. And this is another common example of websites that need to be editable, it's a gallery of paintings, they're actually my cousin's paintings, she's awesome. And you can see multiple ways that you can upload images, you can either choose a file or you can paste or of course you can link to a file, drag and drop. And it all just works.
And this is actually my talks list on my website which started this.
This is basically the first ever Mavo demo, when Mavo was a very, very early prototype, it was built around this list of talks, and then we generalised it as it went, so it was quite cool to be able to finally use it on my actual website.
There is one thing you can see here that I haven't showed you yet, the stats at the top, that says 88 sessions, 79 events, two events upcoming, you can't do that with the features I've already shown you, I need to show you some more.
And also the flag that changes when you change the country. And this is a demo of a simple content manager, pretty much the same idea.
Most of this is just mv multiple, mv storage and property attributes, that's it.
And of course, good old HTML and CSS, there's a lot of CSS here.
You can see more demos by the way on the Mavo website, all these demos are taken from there.
But we'll see more throughout this talk.
So, remember when I mentioned, to reflect the value of an existing property somewhere else, I need to show you something else? So, here I have a slider with the property of strength and as I move it, its value is reflected in the HTML. And this is because I've used the square brackets with the name of the property here.
These are called expressions.
You might be familiar with expressions from other systems, although they're a little different in Mavo, we tried to make them simpler, you'll see how in a bit. But of course, what you expect to work, works, for example, simple math works just fine, of course it also works on attributes, you could, there's a bunch of functions that you could use, this is probably not very useful.
But hey, you could change the slider and see what its square is.
And notice that the numbers are formatted automatically. And you can also give a name to those expressions and use them somewhere else, so you could basically create and declare variables that you could use in other places.
Here, I have an expression that generates this CSS caller and I've also given it a name of caller and I'm using it here to actually set the style of this div, so just with these few lines, we've made basically a fully functional colour picker.
And this is a slightly more complicated example of pretty much the same idea.
Except it also has gradients on the sliders themselves, but it's basically the same thing, it's just a lot of simple expressions here.
And here you can see that all this stuff actually works on XVG as well.
This is something that many people use spreadsheets for, but I think it's a much nicer UI to make it with HTML. But so far, you might be thinking, yeah, I've seen expressions like these in say, Angular, for those of you who have used things like that, but where expressions really shine is when they're combined with collections, mv multiple elements.
Let's say we'll add a heading here with all my cats. I can just, well of course, this is not particularly complicated and it updates as I added the data, I could even add another cat, and oh, right, it should be called cat.
I can add another cat and it updates immediately, but let's say I didn't want to count all the cats, just those with an age.
Notice I can reference any property anywhere in the Mavo app and there are certain rules about what it resolves to. If I use an expression with age here, inside the collection, it would just show me the current age of each cat. Like, Adam Catlace is two, so it's printing out two, Tim Purrners-Lee is nine, it's printing nine, and so on. But if I use this outside the expression, it refers to all ages, so it counts all ages here and I could even have filters.
So, let's say I want to count all older cats that are older than six.
I can just do something like that.
Or I could do an average.
You get the idea.
So, audience participation time, let's hope this works, I haven't done this before, so fingers crossed. The thing I haven't told you, I told you you can store data on GitHub by just using an mv storage attribute that points to a GitHub URL, what I haven't told you is what happens if you login to this app and you don't have permissions. What basically happens is you can edit the data, once you click save, it's saved to your own profile basically, if you know about how GitHub works, it's basically saved in a fork, and you can send an edit suggestion, we can't use GitHub terminology in this because the data might be edited by a client for instance who doesn't know how GitHub works. But there's a button to send an edit suggestion which basically sends a pull request behind the scenes, which makes it really easy to collect data. So, yeah, visit this URL, login with your GitHub account, make some edits, maybe add your cat if you have one, you should be able to upload an image from your phone or whatever, just don't upload a big one, because it's a conference Wi-Fi, it's not gonna be very good, try to crop it or something, save and click edit suggestion and hopefully, if it works, I should soon see it as a pull request once you do that.
Raise your hand if anybody managed to go to step five and everything went well.
Oh, that was fast.
Let's see.
Oh, so notice that I get a pull request here and in future versions of Mavo, we want to show these suggested edits right in the Mavo.
But at least it gives me a URL to preview the changes. Which I opened in a separate tab and...
What, I thought that was an actual edit.
So, anybody that's actually submitted an edit, oh okay, so he just pressed revoke edit suggestion which just closes the pull request.
Let's see.
If anybody manages to send a pull request successfully and with actual edits, please raise your hand. Oh, okay.
I have four to pick from.
Let's close this.
Okay.
Smashed Avocado, (laughing) that's kind of an inside joke. I love Smashed Avocado by the way, you guys have the best breakfast ever.
Okay, well, I'll merge this.
And now, if I go here in my slides and refresh it should be there, assuming there is no cache issue, please, work, yes! (applauding) Thank you.
Another demo, this actually the invoicing system I use, it's based on Mavo.
Of course, this is not with real data, but I actually do use this demo for my invoices, I'd take some file in a private GitHub repo, obviously, because I don't want the entire world to have access to my invoices.
Which actually tells you that private repos do work just fine, you just have to login to read the data.
And I mentioned that I use the same demo, it was different data, I can do that because you can basically change the data for every Mavo app from the URL.
So you find an app you like and you want to use it for your own data, you can just change the URL and use it for your own data.
The person who made the app doesn't even have to know about it.
This is probably my favourite demo, it's the least useful to the general public, I suspect, but I love it, I always wanted to make something like this because I hate XVG paths, they're my least favourite part of XVG.
I hand-code most of my XVG, but when it comes to paths, I can't do it, I have to go to Illustrator, export to XVG and copy the path from there. So, I made this little Mavo app that helps me build an XVG path segment by segment and I can actually tweak the parameters and make change in real time and I can download the resulting XVG or open it in a new tab.
Or just see the path code and copy it.
Actually, if you go to the actual demo right now, because this video is slightly old, you can also change the colours and the thickness of the line, I've actually used this app to draw the logo for the Haystack group, the H with the needle. So, I use this all the time, and it's just a Mavo app. I didn't write any JavaScript to make this app. I mentioned before that Mavo was designed to be extensible, I mean, obviously, it came with some predefined rules about certain elements and some back-ends that are predefined, it wouldn't be very useful, right? It's designed to be very, very extensible, third party developers could write plugins and these are some examples how you could extend.
Obvious extension points, but there are also hooks for lower level extensibility, hooks basically allow you to change how Mavo works.
Like hook into its internals and run different code and change how parts of it work.
In an earlier version of Mavo, the entire expression system was implemented as a plugin via hooks, so they're very powerful.
Sadly, we do need better documentation about all this. There is actually plugins directory already, it doesn't have many plugins, but it does have some.
And you can find it on plugins.mavo.io and of course the entire plugins directory is a Mavo app. And you can see the few that we have, there's a TinyMCE plugin, there's a Markdown plugin, there is a Yaml plugin if you want to store your data in Yaml instead of JSON.
There's a Greek Locale as an example of how to do a localization plugin for a given language. There is a work in progress, a Mavo Firebase plugin from my student Lizzy.
And someone made a PHP backend for people who want to store data on their old servers.
And actually if you click on the Markdown plugin for example, you can see this is also a Mavo app, actually multiple Mavo apps.
I can see these bars now because I'm logged in and notice that there's a description for every plugin, this is because I'm fetching the ReadMe from the repo of the plugin and that's also done by Mavo, and rendering the Markdown in it.
Now, I mentioned that I joined academia and I've developed Mavo in there, so there is gonna be some science. Developing Mavo itself is considered engineering, and to justify my presence there, I do need to do some actual science, and in the case of HCI, the actual science is considered the user studies, like actually testing if what you make is usable, if people can easily use it, do they stumble, are they confused? And even though I said I have to do it to justify my presence there, I actually think it's great that I have to do it, I think more libraries should do usability studies, it's a kind of thinking that is lacking a lot in many open-source projects.
We often focus on getting functionality out there without thinking of how usable it is.
There are some projects that have done user studies, but sadly not enough.
So let me describe how we did the user study for this and it might give you ideas, if you're developing a library or something like that, even if it's just for your team, maybe it can give you ideas how to do user studies for that.
So, we recruited 20 participants, it doesn't sound like many, but it's actually above average for an HCI study, they are qualitative, they're not quantitative, you are not looking for numbers, you're looking to figure out whether what you made is usable and actually you see the same patterns after the first five people or so.
So, you don't have to even collect 20.
So, their demographics were 13 female, six identified as male and one didn't identify as either, the mean age was 35.9 and 13 identified as beginner or worse in programming and seven were intermediate.
Before coming in, we asked them to make a mockup of the contact manager application without telling them why, we told them to only spend up to 15 minutes on it, and seven did come in with the mockup of a content manager app, the others did not.
This was the overall structure of the study. First, we gave them a tutorial on Mavo syntax, similar to what I showed you already, but also with some practise tasks.
And then there was the structured part of the study whose main purpose was to evaluate whether Mavo is usable and learnable and at the end there was the freestyle study which aimed to evaluate if Mavo's capabilities were sufficient for what people want to build. So far, we've been making demos with HTML we wrote, knowing about Mavo and knowing what Mavo needs, but will Mavo be able to work on arbitrary HTML that people work without knowing about Mavo? The first part, the structured study involved one of these two apps, either a foodie log which was a sort of food blog for people to log visits to restaurants and ratings for every dish.
Or a pros and cons app which is a decision making app that lets you make decisions by listing pros and cons and giving them weights.
And there were 10 to 12 tasks with each app, every subject was randomly assigned in one of the two apps. And the tasks were of increasing difficulty, the first few were about CRUD, remember that means create, update, delete, basic data tasks to basically create a simple data-driven application and then tasks whose solution was simple expressions, like just printing out the value of a property or calculating the average or how many items there are, simple expressions.
And the last few tasks were to push the limits of Mavo and see how people deal with harder tasks, like for example an average of averages or conditionals or filtered aggregates.
So, before we started, and before we even told them about Mavo, we showed them a demo of the app without showing them the HTML.
Just how the app works, this is the decision making app. And this is the foodie log.
And we asked them, how long do you think it would take you to build this if you were given the HTML and CSS? How long would it take you to turn this into a fully functional application? So, five said hours, six said days, three said weeks and three said months.
And there were also three more that said, I just couldn't do it.
In reality, it took them about half an hour with Mavo. And all of them were able to perform the CRUD tasks, all of them were able to add the property attributes and mv multiple attributes and turn their static mock up into a fully functional, editable webpage.
The success rate on basic expressions was also quite good, 92.8% and on the last few difficult tasks, one observation that we thought was quite interesting was that people had a lot more difficulty when the expression had to be surrounded by characters that were not white space.
Like, notice the first three, where the expression is surrounded by white space and it's sort of more separate from the rest of the HTML? Everybody got those right.
Every single person got those right, but the last three where there are other characters surrounding the expression and the expressions modifying a part of something else, the success rate was much lower there, like one out of four didn't get it right which we thought was very interesting, like how people seem to have trouble around grasping the idea of concatenation.
And for the last few more complex expressions, still three out of four got them right.
People listed conditionals as really hard, we had a function like this, an if function where if the first argument was true, then the second would be printed out, otherwise the third, and of course it could be nested, people seem to find that really, really difficult.
Someone even said, just seeing those if statements, I did a little bit of Java and I remember those always screwed me over in that class.
No surprise they also tripped me up here.
So, we figured we need to make this easier. So, after the study, we added Markup-based conditionals, but we still haven't tested if those improve things. And also, the perceived difficulty of making these apps dropped two points on a five-point scale.
We asked them to rate how difficult it would be before and after they made it with Mavo, before they even heard about Mavo and after they made this app with Mavo and on average, it dropped two points and these are the more detailed statistics.
It's interesting it dropped much more on the foodie log, people rated it much more difficult in the beginning and actually they found it a little bit easier in the end. This is a summary of the results.
And the last bit of the study, the freestyle study, these are some examples, remember that we told them not to spend more than 15 minutes on it and many of them were beginners, so don't expect the pinnacle of web design here, but it's interesting that all of them were able to convert their own HTML to fully functional apps, even though they had written that HTML without having heard about Mavo.
And some even went home and made apps for their own needs after the study.
Someone made their own role-playing game, WYSIECCG, back then, the name of this was WYSIE, not Mavo, we changed the name to Mavo later.
Someone else made an app to track horse-feedings. I never knew how complicated taking care of horses could be, but apparently, it's insanely complicated, they have very complicated needs about feedings and which blankets belong to what horse, there's a whole, it's almost a science.
So, she had a horse in the stable, and they don't have an app to manage all this, so they just have a huge whiteboard, I should've actually put it on the slides, they have this huge whiteboard with what looks like a spreadsheet from hell where they write on little cells and it's such a mess.
And she made an app for them by using Mavo. And someone else experimented with making a simple bug tracker which you can see at the end.
People seem to overall like Mavo, they found it very simple, many of them were already trying to learn JavaScript and struggling.
So, they remarked on how simple and learnable they found it, but most importantly, they said that Mavo did the things they were struggling to do.
Which was exactly what we were interested in. It's not just about whether it's easy, but also does it solve the problems it's trying to solve? And many people remarked that indeed it does, these were the things they were trying to do and had trouble with.
So, we published our findings in a conference called Wist, it's an academic conference, it's actually the first academic conference I ever spoke at. Pretty nerve-racking experience.
Not because there's anything wrong with the conference, it's just, every new experience is difficult. So, in the world of HCI, it's one of the most popular conferences, so we published a paper about it and hopefully soon we're gonna do a field study as well to see how people use Mavo now that it's released and that it's in the wild.
And of course, I've showed you what is there, I showed you a small percent of what is there, but there are so many more things to be done, like, literally, I don't think we've done 20% of what we want to do.
Some of the things we want to do is granular access control, this is like a top priority for me.
The back-ends that we support for storage right now don't allow for this, so we haven't worked on supporting it.
By granular access control I mean, let's suppose you have a collection for instance, and you can only edit your own items, you can only edit the items you created, this is such a common pattern. Let's say you want to make a blog, it's kind of useless to have a blog where you can edit everybody's post or everybody's comment.
You should be able to only edit your own items and because we're storing data on GitHub or Dropbox right now and it' stored as one file, the back-end itself doesn't support it.
But now that we're developing a Firebase back-end which does have this kind of granular access control, then now it is possible to implement it and I think this will open up a huge set of applications to be built with Mavo like blogs and discussion forums and all sorts of things.
Also, servers and updates.
Again, for the same reason, the existing back-ends didn't support anything like that, but there are other back-ends that do, so Mavo should support it and I think it will be very cool to be able to have an app that updates automatically, without having to write any JavaScript to do this. Imagine having a chat that is just made with Mavo, just HTML.
Also, server-side rendering, often when you make connectable website, you don't want the data to load after the webpage, you want the webpage to load with the data right in there.
And you want the webpage to not depend on Mavo being included, so server-side rendering would really help there or just being able to store data directly on the HTML page.
For example, if it's stored in GitHub pages. Filtering and sorting.
It's actually possible to do some basic filtering and sorting with Mavo expressions in CSS, but it should be easier.
Pivoting is basically, remember the foodie log which was a list of restaurants with a list of visits and each with a list of dishes that you at at that restaurant, what if instead, after you stored a bunch of data, you want to change this view to a list of restaurants with a list of dishes and the visits, the dates that you ate each dish? Right now, you can't really do that very easily. And the general case of just being able to point to data in other places.
And I think it would be very cool to be able to make apps for devices with Mavo or mobile apps, so that would be something really cool to work on. And if that sounds interesting and you want to get involved, it's an open source project.
It was released in May, there are a lot of needs, if you can write JavaScript, you could write a plugin, or you could work directly on Mavo, there are many open issues.
If you don't write JavaScript, you can help improve the documentation, a lot of things to do.
So, that's what I had, thank you very much. I actually had stickers for you, but my luggage got stolen before my trip to Australia, like somebody broke into my car.
Does any of you have a smart car or is thinking of buying one? Good for you, apparently they're a piece of cake to open. So, yeah, no stickers today, just me.
So, thank you very much.
(applauding)
