Building the Minimum Viable Experience

[JimCollinson]

The Minimum Viable Experience (MVE) is what we are working on first, so we can have all the basic components of a fully functioning and usable Network ready to go prior to launch, and then iterate and improve, from there. It’s the first set of features we’re designing and building, before we rattle on through the rest of the UX Roadmap.

As I mentioned in last week’s Dev Update, we’ve been working toward an MVE, prioritising, designing and developing the essentials first, lining up the stretch goals, and working through which features don’t quite qualify.

So here it is, detail of all the features that we feel should comprise the MVE, and how we’re prioritising them, in a live Figma File:

The features are grouped in to some seeming fairly arbitrary categories, but really they are just a useful way for us to consolidate feature sets when putting prototypes together.

What you’ll see here is also work that has been completed from a Design standpoint, what is underway, and what has been conceptualised, but not been through the design process yet.

There are also corresponding boards for Frontend code, APIs and Safe Client Libs, and also the Backend code required to enable these things. I’m afraid I didn’t manage to assemble those boards in time to publish them today, but I’ll add them in due course.

I hope it helps paint a picture of what you can expect, and how we are choosing to order and prioritise development.

Fire in with any questions, and please do let us know your thoughts… we’d expect nothing less!

[david-beinn]

Looks great Jim!

Not sure this is the place to be asking it, but it did make me think of something.

Currently, how does an app identify itself? My understanding is that it might be trivially simple to impersonate an app, and eg. steal Safecoins.

Hopefully I’m wrong, but if not, feels like it might be something that needs fixing for MVE

[JimCollinson]

I’m probably not the best person to answer with the detail you might be after, but no, it should be pretty damn difficult to do that.

Each app can be verified by the user as unique using a key. So even if an app developer made an app to look and feel authentic, it would always appear as a separate duplicate but unique app, and have to be granted it’s own permissions.

Additionally, the permissions for spending Safecoin (in the course of using an app to edit data for example) and the permission for transfering or paying with safecoin, are separate and distinct. So you’ll have specific control over which apps can transfer coins, and therefore ‘steal’. It’d be defaulted to off, natch.

[david-beinn]

Thanks Jim, that makes sense.

Just hadn’t spotted anything anywhere about a unique key, so wanted to check that was how it would work.

[Josh]

Very cool to have, thanks Jim.

P.S. be ready for @Sascha I spotted some typos!

[JimCollinson]

Figma’s lack of a spellcheck exposes my hamfistedness!

[JimCollinson]

@david-beinn

Just hadn’t spotted anything anywhere about a unique key, so wanted to check that was how it would work.

Yeah, this is some of the functionality we get via Labels combined with BLS.

[bochaco]

@david-beinn

My understanding is that it might be trivially simple to impersonate an app, and eg. steal Safecoins.

This is something we briefly discussed over the past few weeks with some ideas to solve it in the medium/long term. E.g.:

• Perhaps apps can be published on SAFE and users can bookmark them with immutable URLs (safe:// URLs which have a specific version and on the perpetual web). These bookmarks can then be used as the launching location for the app. The browser/CLI/SNAPP could pull the app’s binary/binaries from one of your bookmarks (which assures you are pulling the exact same version of the app you trusted before), and then run it.
• Simply use the OS keychain perhaps (Keychain (software) - Wikipedia)
• Some more complex ideas were being thrown, ideally to make it a bit more secure, perhaps there could be a SAFE filesystem (i.e. create a driver for the OS, analogous to an ext4 driver) which can perform hash verification before allowing the OS to launch an application, so you could have some SAFE partitions in your hard drive that you know the apps binaries can be verified when the OS requires access to them for launching the apps, so it sounds kinda similar to the way some mobile phones are putting some secure crypto key storage…note these are all just ideas without much deep research on them.

[BambooGarden]

i like this greenish taint that it has to it

[Sascha]

Thank you, @Josh, for alerting me. This looks like a very good and much needed document. I never used Figma before, so I wonder how to best go about proofreading the documents in a systematic way. Maybe they could be exported into something that has a spellchecker?

I only took a quick look, but here are some errors:

auto generated → auto-generated
rphbust → robust
ghenerated → generated
credientals → credentials
strong, → strong

[JimCollinson]

TBH, I’m not sure I’d spend much time on it. It’s not a marketing’s document per se, and is really only to keep the team aligned, and community up to speed. So long as the message is understood, I’m all good with a typo here and there.

The reason it’s in Figma is because it’s always readily at hand, and beside all the design > dev handover documents and prototypes.

[Sascha]

Well, I think even forum posts are part of marketing in a sense. At some point typos actually start making reading difficult, e.g. “rphbust” above. And I believe general impressions are important. One of the reasons I like this forum and became interested in the project is that people tend to write like adults, i.e. serious researchers, not just kids swiping away streams of consciousness on their phones.

[JimCollinson]

You should be a able to leave comments directly in the Figma file to point out and egregious errors. That’d be the handy way to do it.

But what I mean is, don’t worry about cracking open a spreadsheet for it, or anything more than you’d do for a Github issue etc.

I hope they put a spell check or something in Figma in the future. As some one with dyslexia I tend to lean on them pretty heavily!

[andyypants]

One thing I am really not getting a feel for here is how this will be a MvE specifically. I mean lets look at a basic function. Start a vault. Ok so we can start vaults. I would hope even in MvP we can do that Do I have to go into some command line interface to do it or will it be a nice clicky walkthrough like installing a new video game?

[bones]

Just because something is part of the MVE does not mean it would not also be part of the MVP, in my mind anyhow.
I’m pretty sure command line interface is no good for MVE, that would not be a good experience.

[JimCollinson]

@andyypants

One thing I am really not getting a feel for here is how this will be a MvE specifically.

As I say in the description at the top of the file (and probs should have done in the post) all of these features will be part of a suit of apps accessible via the Safe Network App, not a CLI.

@andyypants

I mean lets look at a basic function. Start a vault. Ok so we can start vaults. I would hope even in MvP we can do that Do I have to go into some command line interface to do it or will it be a nice clicky walkthrough like installing a new video game?

Have you seen the walkthrough of the Vaults UI? This is the design work that’s already been completed against the MVE, so it should give you a flavour:

Building the SAFE Network UX | Vaults

[andyypants]

oh sweet no I had not seen this yet! Ya I think that deserves its own comment in the main section. @bones has a point if its in MvP its necessarily also part of the set of MvE features I was just looking though it and trying to pick out what were the new things being added now that MvE was the goal for Fleming and I could not spot much that would not have just been in the MvP anyways. Well if that’s how it is those people being like omg another delay in Fleming release should rest easy that its not another huge project to make it to MvE quality.

[JimCollinson]

@andyypants

oh sweet no I had not seen this yet! Ya I think that deserves its own comment in the main section. @bones has a point if its in MvP its necessarily also part of the set of MvE features I was just looking though it and trying to pick out what were the new things being added now that MvE was the goal for Fleming and I could not spot much that would not have just been in the MvP anyways.

To quote myself from the dev update the other day:

@JimCollinson

So, there are multiple strands that run in parallel here, it’s not all sequential. But if you think of the MVP (roughly) being the infrastructure of the network, and the MVE being built on top, but encompassing the frontend and complete UX stack.

So if we just wanted MVP and no more then that would really be Maxwell (Fleming + the ability to upgrade it), but MVE is what we think is the minimum required a full launch. We’ll likely hit those requirements ahead of Maxwell, but and keep on powering through iterations and pulling in features, so we’ll have more than the minimum for launch time. But the game plan revolves around getting that MVE locked in, and then plowing on from there through the UX roadmap.

[andyypants]

ya that’s what I kinda thought. MvP is like the under the hood part that makes anything actually work at all and MvE are the UX features built on top. In that list most seem to only go as far as the functionality (MvP) and not really dig in to what we can expect in the UX.

I do understand a big element of UX is the synergy of how it all fits together so like maybe I should just assume in brackets after every feature it says (and this will fit into an overall interface where non-tech-savy people can use the function easily.)

[Krekc]

Nice video, loving the designs. When I see this my hands are itching to get to farming and all the other things we’re going to be able to do on the network.