Rethink our product presentation as a multi-backend tool (closed)

Events
1

Once 0.10.0 has been released i’ll upstream some fixes which i already applied in export.5apps.com and import.5apps.com, and we can make sure all three backends (remoteStorage, GoogleDrive, Dropbox) work correctly in 0.10.1 or whatever is the next release (something which has been in the making since Adding Dropbox and GoogleDrive support to remotestorage.js in July 2013). Then we can make this public in our documentation and marketing material.

I think this is a good moment to rethink our project presentation from scratch. On remotestorage.io we want to present several inter-related products/things:

App developers

  • Get started with writing unhosted web apps. It’s a big change in how you think about your app; most developer think “my app’s app data” instead of “my user’s user data”. Part of this is also done on unhosted.org, but it doesn’t hurt to spend a lot of attention space on this in the main remotestorage.io main page first text people read, and info graphic.
  • Use remotestorage.js as a library that gives your app access to the user’s data (3 backends)
  • Remotestorage.js is also pretty good at asynchronous synchronization, indispensible for any serious offline-first app. Who is our competition here, actually? PouchDB and Hoodie mainly? How good is Firebase at offline-first for instance?
  • Get started! (starter-kit + screencast)

Redecentralizing the web

  • Our remoteStorage spec is the only contender we are aware of to standardize per-user storage on the web.
  • Please join the spec discussion on github or at IETF apps-discuss.
  • Proprietary interfaces to user data should at least implement CORS headers (GoogleDrive and Dropbox do this and our library supports them; we talked to tahoe-lafs and ownCloud about it; everybody should - link to enable-cors.org maybe).

Set up your remoteStorage

  • Providers; get an account.
  • Server software and install instructions.
  • Build your own server using our nodejs reference implementation.
  • Or read the spec and do it yourself entirely.
2

Just 2 comments before diving in:

  • Please use proper grammar and most importantly capitalization. It’s extremely tiresome reading long posts without these important hints about the content to eyes and brain. Thanks!
  • It can’t be a patch version, but has to be a feature version by definition, making it 0.11 then. However, I don’t think it can be release that quickly, as the features are missing a lot of tests, and nobody worked on the UI/UX properly so far (which is sorely needed in my opinion, as it’s just a hack right now).
1 Like
3

sure, when switching to the new product presentation, let’s label GoogleDrive and Dropbox as ‘experimental’ at first (they only show up when you activate them, anyway). that way they can also get some more alpha/beta testing and feedback/contributions from people who are interested in it, and it’s clear to everybody (both people who use it and people who don’t use it) what they can expect.

1 Like
4

He’s right on this one. I have been thinking about that quite often lately, because if you tend to write longer posts, or even for short GitHub Issue comments, the contents most fine. But often not clearly understandable. I understand, from an aesthetic point of view, that lowercase writing ins stylish.

But if I want to make myself understandable, or if I were the advocate preaching a new teaching, I would consider raising my attention to What and How I am saying things. It’s a simple equation : if you polish your language, more people will be able to understand you, therefore be more willing to cooperate.

Edith : Look at the writings from http://unhosted.org, they are easily understandable.

5

OK, added capitalization. I’m surprised nobody has any reactions to this, though. How we present our product is super important, and I don’t want to update it without thorough discussion with the whole community first. Doesn’t anybody have any comments or modifications?

Please all provide some input/reactions to this if you can! It will help make the end result a lot better than what I can do on my own.

6

Not sure what to add or edit. If you’re talking about the new website, it’ll be very helpful as input. I’ll be working on that again after the 0.10 beta is released.

7

As the remoteStorage release cycle is stressing me a little, and because I it’s impossible for me to know all the details (i.e. from PRs), I’d like to ask a thing here:

  • Could we provide a Trello Board providing a little structuration of current and planned work packages. No need for timelines or Roadmaps in continuous-delivery-world. But I’d like to have a simple representation about what’s up next that is not linear text and rather a 2D visualization of any kind.
8

In regards to core library development, it’s all about the sync-per-node PR and releasing 0.10 with the caching/sync rewrite. After that we can do multiple things at once, which, as you suggested, we should probably collect and list somewhere.

1 Like
9

Well, for instance: Do you like the three headers? Do you agree they are in the right order? And for each header, do you agree all the relevant subpoints are there?

For instance, I think the first one, ‘App developers’, needs a catchier phrase, that speaks to app devs, and puts the reader in the right direction of what this website will tell them. What about “remoteStorage: Add per-user data to your web app”, maybe?

I think there must be a misunderstanding here. I am proposing that we rethink our product presentation, and this is an important topic, right? Yet you don’t have anything to add, or to edit, in any of the content points I proposed? It feels like we are not talking about the same thing, maybe.

Yes! I am talking about actually changing the content of the website, http://remotestorage.io/. I propose to remove all the current texts “Webfinger+OAuth+CORS+REST”, “wheels included”, “compatibility is king”, etcetera), and put this new “app devs / redecentralize / set up storage” structure with all its subpoints etcetera in their place. Maybe that wasn’t clear, sorry.

I am not just proposing this in theory, I want this content to actually go onto our website. Your use of the word ‘input’ suggests you do have things you want to add or edit before this goes onto the website, right? Maybe you want to throw all of it away and do something completely different? Maybe you want to keep the current content? Please, speak your mind!

OK, great! In that case let’s pause this discussion for now and then let’s all (whoever wants to join) work on it together in maybe a few weeks from now.

1 Like
10

What I meant is that you can’t just put an outline of text 1:1 on a website, so it can only serve as input.

1 Like
11

Let’s get together the weekend of 3/4 May as we said at the meeting, at the Rebel Base to try to:

  • get this outline transformed into html
  • launch the responsive redesign @raucao has been working on
  • if there is time left, update the Discourse software to a newer version
12

We still haven’t talked about this properly with all the contributors and stakeholders of the project, let’s put this back on the agenda.

I implemented some changes to this extent in the website’s main page, but those were then reverted again by @raucao.

Everybody, please compare the current list of benefits on http://remotestorage.io/ and my improved ones on https://rerelaunch.5apps.com/ (ignore the layout changes for now, let’s only focus on the text changes).

I think the new ones are better because:

  • They talk to the web developer instead of to the end user
  • They mention how remotestorage.js is a tool for multiple backends (not only remoteStorage but also Google Drive and Dropbox).

@raucao please explain why you reverted my changes, and what we can do to make you happier in your role as a contributor to the project, and as a stakeholder in the technology we’re building.

13

See also this PR on the remotestorage.io github repo: https://github.com/remotestorage/remotestorage.io/pull/70

14

I reverted your changes, because not only did you not seek consensus first, you didn’t even seek technical review, and indeed they broke the layout of another page. We can discuss content details on GitHub in your PR.

lolwut?!

15

I’ll organize a team meeting to discuss these issues.

@galfert @Ragnis @silverbucket @raucao when would be a good time for you?

Wednesday 8 september 16:00 Berlin time, for instance?

16

Even though I’ll do my multi-backend tool marketing in another way (see https://github.com/remotestorage/remotestorage.io/pull/70 and https://github.com/unhosted/u36/issues/5) it might still make sense to do a team meeting at some point. When do people have time?

17

I guess you meant 8th of October not September, right? :slight_smile:

That whole week I’m quite flexible, so I leave it for the rest to say what fits best for them.

18

I’m in PST until end of October, so anything before 19:00 CET doesn’t work for me at the moment.

19

Right, yes I meant October :slight_smile:
OK, so how about 8 October 8pm?

20

Great. I’m in.