the third flow serval needs is onbording: how to guide initial users from installation to use. that’s VERY important, even more regarding mesh networks. there’s a lot to educate. This one I don’t have much done, i do think we need to agree on a hangouts meeting and doodle something. without proper onboarding, there’s no adoption.
I added all ideas and notes that are NOT official on this folder. I have a layout of QR system (barcode.pdf) and even some overall screens I designed before talking to Paul (screens.pdf)
the folder is open for view, DO give me your google credentials if you want to edit. I’d love some collaboration.
As I told Paul, it’s hard to do design work for open source projects, simply because designs are not broken or fixed, we crave approval to go to the next step. I don’t mind doing it via email, but since Paul told me the core group is pretty small, I’d appreciate if we meet for a hangout soon. My 1hour talk with Paul helped me a lot, and I need to interview you guys properly. Otherwise it’s not design. just fancy pictures.
Take care, sorry for the long email, and do let me know your opinions.
Nicholas Frota >> frontend
+1(917)512-1486 >> phone,
nonlinear >> twitter,
nicholasfrota.com >> blog
You received this message because you are subscribed to the Google Groups "Serval Project Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-dev...@googlegroups.com.
To post to this group, send email to serval-proje...@googlegroups.com.
Visit this group at http://groups.google.com/group/serval-project-developers.
For more options, visit https://groups.google.com/d/optout.
I hear you. Asynchronous communication is the key.
I don't think a twitter like app is enough to bring users tho. It's doable use. Just not enticing.
And yes... Maps need to be downloaded. Regions need to be defined. If that's the case, it should be part of the onboarding.
Regarding the time, yes... It's complicated. There the time it's sent. The time it's received. The time it's read. That's a lot to take.
Are local clocks THAT unreliable? Or is it just a 80/20 thing, we can build on top of it, just not use it in critical mission?
Can we ask to check the time at the onboarding?
I understand it's a technical failure, but since user and system goals are aligned (there's no benefit for the user to fake the time) I don't think it's a big deal.
Is there any study that tells how many devices are not in sync? I take its not a deal breaker.... But maybe I'm glossing over.
Would it be doable to use age, i.e. relative times? Like time_sent - time_written or time_sent - time_received ? And adding those in each hop? Just hoping that the clocks are a bit self-consistent...