What should the first interface be?

[Procrat]

At some point far in the future, it would be great to have multiple user interfaces, so everyone has something that fits their needs. However, for bootstrapping, I think it would be a good idea to entirely focus on one user interface for the time being. The current CLI was a quick win and is easy to play around with, but its current intention was not to be a great user-facing tool.

It seems to me that a GUI would be attractive to the largest group of people. A command-line interface seems burdensome to use and even other kinds of terminal interfaces will restrict Eva to only be used by tech savvy people.

Within the domain of possible GUIs, I can think of three kinds, with the following pros and cons. (I'll keep it updated when others are mentioned.)

• Web interface
  • Pros
  • Very accessible
  • Easily updatable
  • Cross-platform for free
  • Cons
  • You have to make an account to use it
  • Possible cons
  • You have to be online to be able to use it. Offline usage with delayed syncing might be doable, but perhaps a pain. (Does anyone have experience with that?)
• Offline GUI
  • Pros
  • Offline usage
  • Cons
  • Extra barrier of downloading and installing
  • Possible cons
  • Are there decent cross-platform graphical toolkits?
  • How should updates be handled? Forced (cfr. Steam)? Full user-control (with the possibility that some users will fail to do so)? Something in between, i.e. nudging the user until they decide to turn off that message? :smile:
• Mobile app
  • Pros
  • Rather accessible
  • More likely to have a smartphone on you than a larger computer
  • Cons
  • I personally don't like using smartphones, especially typing on them feels like a pain
  • Extra barrier of downloading and installing (which I feel is a bit lower on smartphones)
  • Might be too separate from your workflow on your computer
  • Possible cons
  • Same questions about updates
  • We must support different platforms unless languages/tools that combine this are decent enough these days. (Does anyone have experience with them?)

There is an intention to have a strong separation of the different parts of Eva as to make it easy for other interfaces to be written as well. If anyone strongly objects to using a GUI, it should be made easy to write another kind of interface and I encourage to do so. However, during these early days of Eva, I would really love it if we could agree on one kind for starters and work together on it. :smile:

Tagging some people who might have interesting ideas about this: @Silox @NoctuaNivalis @iasoon @tivervac @wschella

[iasoon]

I'd go for a web interface! Web interfaces are the catch-all clause; they work everywhere. They are easy to create and use, are familiar, have a great on-boarding experience (no need to install anything) and in this modern day and age you can even make them available offline through something like electron (I'd guess alternatives for mobile exist as well). If you want a 'proof of concept' UI that works sufficiently well and inspires people to write their own alternative interface, I think this is the way to go.

I think GUIs are great for overviews and managing, but for actual in-the-moment usage (entering tasks, marking them as complete, ...) I'd probably prefer an interface that keeps out of the way, like a CLI. A cool way to implement this for not-so technical people (and even for technical people) is having a chat bot on your favourite communication app. I feel the model of a normal conversation is the way I would actually like to interact with Eva, so I especially like this idea. It would probably be my preferred interface when I'm on mobile, as I don't want to review or organise when on the go, but just enter or fetch data quickly.

[wschella]

If the goal is (ultimately) to create a cross platform (Linux, Windows, Smartphones, ...) application, that actively syncs between platforms, there's only one viable option that doesn't implicate a tremendous amount of duplicate work (Am I right in assuming this is the goal? ). The Web of course. At least a lot of technologies commonly associated with the web, a la HTML, CSS, JS. You immediately have a basic cross platform interface that is able to sync easily (assuming there is some server running somewhere).

To solve the problem of offline usage, you would need clients for every platform (Qt + React Native would cover most), but the problem would still not be trivial. What if the application is closed before the sync happens? Do you deamonize? Those are just the same questions, with a little more flexibility.

Another strong point for a web interface, you could run most of the same code locally on a headless browser, (something like Electron), if there is a need.

+ You force yourself to immediately separate concerns (API vs Visuals).

Edit: @iasoon sniped me

[ninewise]

What you guys seem to have forgotten, but I think would be the best interface, is a web GUI with a server on (e.g.) your own device. You get most advantages of a web GUI (familiarity, cross-platform graphical toolkit) and a local application (offline usage).

It also opens choices for the user: you might want to run Eva on a server somewhere. You lose offline usage, but you enable using a mobile site on your smartphone.

Furthermore, this would force Eva to have an awesome API and a lovely split architecture. This would also help me to write my own calendar stuff, because it's the architecture I'd use and this would allow to have a single interface for both backends :smile_cat:

[iasoon]

I think I disagree, @NoctuaNivalis . Running a server on your own is inferior to running an electron UI (since you don't have direct file system access, for example), and when you run it on a server you don't have offline access.

I think it is more useful to let the eva backend sync with other instances (such as your other computer, your phone, your server).

[wschella]

@iasoon you still need a server running somewhere right? It doesn't have to be on your own device. Or would you have each client ( read platform application) also function as a server themselves and sync with the other clients? Cause to me that looks like a bitch to implement.

In the case that it doesn't, so we have a an API only server, it can run locally or not. As I assume it are only the more technical users that would set up an own server like @NoctuaNivalis proposed, they could, as I imagine this could will remain open source.

[iasoon]

@wschella As soon as you want offline funcitonality, you need the full eva core (unless you just want to add or view tasks, and not actually use eva). If you want both this and syncing, you need a distributed architecture, you can't really get around that. Implementation is some additional work, yes, but it's the only 'real' solution.

[tivervac]

Can't we just mix both? A server can happily be a part of the distributed net. I would like to have as good a sync as possible with as little as possible single points of failure. A distributed network that has a 99% uptime (even less would work I guess) seems like a good fit for that. Wouldn't this mean that the eva-core, doing the scheduling and stuff, would have to be implemented in something entirely cross-platform?

[TomNaessens]

Feels like overengineering a lot in my opinion. Peer to peer networks are hard to set up (the opening of ports only) unless the actual syncing is done using a file and something like Dropbox and even then, you'd still need the full scheduling power/code/core on each device you have.

Syncing with a central API server (single point of failure, how often is a website down anyways?) seems enough for the few offline moments I have. And even then, when I'm offline, I'm probably doing something where I have no need to schedule and/or add tasks.

I'm in favour of something that is easy to set up and is easily reachable. An API with a centrally hosted frontend (that could be packaged in an Electron/React-native/Cordova/... for those who really want an app). The only downside I see with this approach is lack of notification support, which can be remediated by adding calendar-integration.

As Eva is open-source, people who actually want to run it on their own hardware can do so.

From a development point of view, an API + frontend is by far the easiest and quickest to get a POC up and running (short time to market) and available for everyone (least amount of investment for users).

[ninewise]

As Eva is open-source, people who actually want to run it on their own hardware can do so.

You'd have procrat provide a server on his (hired) hardware?

By having each user deploy their own API-server on their (hired) hardware, you can avoid all user-management.

[iasoon]

@Silox a distributed architecture does not imply peer-to-peer networking. Git is distributed as well, and probably a much better fit for this domain. As @tivervac notes, you can very well have an 'authoritative server', kind of like how we use github.

To clarify: I'm not saying this is what should be implemented, I'm just saying that if you want to schedule tasks offline and sync them, this is what you need.

For a simple first interface, I am very much in favour of the solution @NoctuaNivalis proposes: a simple locally-hosted web server.

[TomNaessens]

By having each user deploy their own API-server on their (hired) hardware, you can avoid all user-management.

You'll probably need a form of authentication when deploying your own API too. It will need to be available publicly if you (for example) want to sync your phone and you don't want anyone else to be able to query your tasks.

There are of course easier ways without actual users (a secret key would be enough), but eventually, if wanted in the far future, it would be an option to offer the service as a website alongside a self-hostable solution.

[iasoon]

I'd forget about the users. Supporting multiple users requires significant effort, and I would prefer this effort to go into awesome functionality.

[rien]

I think Eva needs to have two interfaces: one with the user and one with persistent data.

User Interface

This needs to be as cross-platform as possible, while remaining flexible and open enough to slap something very OS specific on it. So I suggest the following flow: Web client <- Web API -> Web server <- Rust API -> Eva This could all be packaged in one application, if needed. But parts can be interchangeable (if @NoctuaNivalis wants to write his calendar thing he could use the Rust API if he plans to run his program on the same machine Eva is running, or he could let his program speak to the Web API if they have to run on different machines).

An example of the 'default' configuration could be a React app, talking to a Rust server running in a Docker container built on top of Eva. This could all run locally, or you could use a VM to host the server if you like.

Data Interface

This is something I talked about earlier. Now, Eva uses a SQLite database, but how I imagined it to work was on a file system. This has the benefit that git can be used to decentralize storage, but keeping a central syncing point. I very readable format would be nice to have, so our simplest user interface (for inserting data) could be your favorite text editor.

[Procrat]

Thank you all for your valuable inputs! If I try to distil the main ideas of what has been discussed so far, I notice that you all really like web technologies and you're in favour of either

1. a local server serving Eva's core wrapped in HTTP API and a front-end, accessible from a browser or SSB, (optionally) backed by a remote server to do syncing; or
2. a remote server serving Eva's core wrapped in HTTP API and a front-end, accessible from a browser or SSB.

These seem both like very valid options for different reasons.

1. With a local server, offline usage is always available and the reactivity is not dependent on your wifi signal strength.
2. A remote server is the easiest to set up and get running very quickly for us, it has no quirks for distribution and is presumably more accessible because it doesn't require downloading things.

For these reasons, I would hope that at some point, both options would be available. However, I currently see no way of getting to that point without a bunch of duplication or hacks. One of the main reasons being that in the first case authentication is needed for syncing, but you explicitly don't want authentication for interacting with Eva, whereas in the second case authentication is needed for interacting with Eva and no syncing is needed. If anyone has ideas on how to make both options compatible, I'd love to hear it!

It seems like a reasonable roadmap to start out with option 2 but keeping these future possibilities in mind and ensuring that the storage/sync backend is nicely separated, potentially already going as far as to run it as a separate daemon on the server.

(Thanks for your reaction, @R13N; I just noticed that I forgot to tag you the first time around.)

[iasoon]

@Procrat I don't really follow your conclusion. If you don't implement user management in Eva core - which sounds like a needless complication to me - you can't really offer a hosted solution, so the user will have to host himself anyways, thus downloading and setting up things. Unless you do want to implement separate users?

[rien]

You don't need to complicated user management in a hosted solution. Simple HTTP authentication should be enough.

On Sun, Sep 3, 2017, 09:48 iasoon notifications@github.com wrote:

@Procrat https://github.com/procrat I don't really follow your conclusion. If you don't implement user management in Eva core - which sounds like a needless complication to me - you can't really offer a hosted solution, so the user will have to host himself anyways, thus downloading and setting up things. Unless you do want to implement separate users?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Procrat/eva/issues/6#issuecomment-326789745, or mute the thread https://github.com/notifications/unsubscribe-auth/ADE9c6g-kLN-Yat52oMuaPDxqbgs9R6Cks5selmvgaJpZM4PDqF6 .

[iasoon]

@R13N The logic should be made aware of multiple users, and every thing in existence should be scoped under their user.

[rien]

By writing a wrapper around Eva, that chooses the a different database for each user and handles the authentication, Eva does not have to know it serves different users.

I think my point is the same as yours: Eva doens't need support for different users, but is has to be flexible enough to support it without much effort.

On Sun, 3 Sep 2017 at 10:21 iasoon notifications@github.com wrote:

@R13N https://github.com/r13n The logic should be made aware of multiple users, and every thing in existence should be scoped under their user.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Procrat/eva/issues/6#issuecomment-326791282, or mute the thread https://github.com/notifications/unsubscribe-auth/ADE9c3dgOoEsiJSwIe75QtGmericF4zwks5semGHgaJpZM4PDqF6 .

[Procrat]

I had some ideas along the lines of what @R13N is saying indeed. I agree that the core of Eva shouldn't be concerned with user management. It does make things a tad bit harder though.

Lately, I have been reading up on the interop between Rust and JavaScript by compiling it to asm.js. This is a quite recent thing and hasn't reached a very ergonomic state yet, but it works! I played around a bit with it, as you can see here. Having Eva's core run on the client is very interesting from an architectural point of view. The client can deal with the storage so our remote entity doesn't have to. And we get offline usage and bandwidth independence for free!

Implementing this with client-side storage also means that we'll move towards having a pluggable data interface like @R13N suggested. Despite the unergonomic-ness, I strongly feel like this is the right way forward.

@iasoon: If you feel like I missed something in my conclusion, feel free to add to it or propose something different.

[Procrat]

I have a minimal example running in this new eva-web repo with a demo here. It feels really nice to have all the benefits that were mentioned and almost no downsides! :smile:

Thanks for the fruitful discussion everyone! I might not have thought about it this much what all your help!