dwyl / app Goto Github PK
View Code? Open in Web Editor NEWClear your mind. Organise your life. Ignore distractions. Focus on what matters.
Home Page: http://dwyl.github.io/app/
Clear your mind. Organise your life. Ignore distractions. Focus on what matters.
Home Page: http://dwyl.github.io/app/
Here's one I made earlier: https://github.com/ideaq/hapi-auth-jwt2
Help very much appreciated with breaking it! ;-)
I've not seen anyone else do this and its very simple to do.
The question is: would it get annoying/distracting? in which case the person can just disable it.
From a mobile perspective especially, will it be handy for our people if the timers works offline?
This would account for places with little or no network (the underground), smaller data plans or travelling abroad.
Is it useful functionality?
P.S. There's an open question as to whether is just be just the timers or other functionality that should be available offline too (such as non-realtime reports), but this level of detail will come from our MVP learning.
Remove hapi?
Some people will want:
There will be other actions. But the question is: should we make this a thing?
The _Plan_ is to Open Source as much of our development as possible to encourage collaboration and reduce the duplication of effort.
But _which_ of the many licenses is the most appropriate?
Moving the project to ideaQ means its easier to include people in the development.
But it means we need to update all the badges...
Do people expect to be able to login with their Google Account? or is an email and password enough for now? [ MVP or Post MVP ? ]
The "industry standard" is to have a 'Remember me' style tick box at login and allow people the option of being logged out or staying logged in.
Given we are creating a time logging app, do we feel it is necessary to provide this option to people?
Should we log people out after x amount of time?
Two concerns might be: legal (I don't have any insight here if anyone can shed some insight?) and familiarity/perception of privacy/safety.
We need to know what our guiding principles are to ensure:
a) facilitate our decision-making
b) let people know what we're about so they can determine whether they identify with our ethos
Related to: #42
given the speed (low latency) advantage of using Redis (in-memory) Caching, it makes sense for session tokens.
Given how simple the MVP UI is going to be, can we build it using basic HTML5 + JS (without any framework) and just focus on the usability for now? To that end I propose that the only Front-End testing we do is https://saucelabs.com/ ... thoughts?
This may appear to be a minutiae detail, please ignore if you aren't interested in naming.
" The words we use make a huge difference " ~ Don Norman
"One of the horrible words we use is 'users'.
I am on a crusade to get rid of the word 'users'.
I would prefer to call them 'people'."
Don Norman on https://en.wikipedia.org/wiki/User_(computing)#Terminology
The easiest way of referring to the people who use an application is as "users" ...
I've never been a fan of calling people "users"...
( I associate the word "users" with people who take narcotics ... )
I would prefer to refer to the (enlightened) people who use our app as a person (singular/record) and people (plural/collection) ... but if anyone else
has a suggestion for a better collective noun
Note: I love the word "Team" but think we should reserve it to refer to the people who are building the product... what do you think?
Further reading: a better word: http://ux.stackexchange.com/questions/11401/better-term-for-user
Bonus Level: (Don Norman's) Ted Talk on Design & Emotion: http://www.ted.com/talks/don_norman_on_design_and_emotion
people
to describe the human beings using our App(s) so that we never have to have the "Users" discussion again.
README.md
of this repo and add a brief paragraph summarising exactly why we avoid the term "User" or "Users". The term is obsolete and companies/apps that continue using it are showing their ignorance of this fact.Should we require people to confirm their email address by clicking a link we send to their email address?
I'm not a fan of how Lab uses Domains for catching exceptions.
(domains are considered "Unstable" according to the node.js API ... )
When a person visits the home page, the (front-end) Boot script should check if the device/browser has a Token saved from a previous visit.
If the person has previously used Time we should try to load their existing timers.
Otherwise assign them an anonymous Token so they can try the app: #58
Especially for the MVP stage, the ideal is to have a way of allowing people to take the app away, use it in their natural environment and be able to give us feedback from anywhere within the app without much effort.
Feedback is a pretty huge topic and will require more thought soon but for now, there are two questions:
As a _person_ that uses an API
I need helpful, descriptive and semantic _Error Messages_
so that I know when something is not working.
See: https://blog.apigee.com/detail/restful_api_design_what_about_errors
Start a basic timer.
To _minimise adoption friction, when a person first arrives on the site/app we should allow them to try starting timer(s) _without registering or logging in. This means they are anonymous to us. ๐ฎ
To make this work we need to assign them a JWT they can use to interact with the app anonymously.
if they decide to register their email address (and thus keep their timer(s) securely saved) their timer(s) will be owned by the email address they register with.
further reading: http://www.forentrepreneurs.com/time-to-wow/
As a user should I be able to continue a timer I have stopped/paused?
Or should the act of starting always create a new timer?
p.s: I don't know if this is MVP or Post MVP... #help ...
@iteles @NataliaLKB @FilWisher do the "other options" allow you to continue a timer you have stopped?
What is the simplest Privacy Policy you have seen (on any app/service) you use? (share links if possible). What do we need to cover?
html
file in the project.dwyl.com
(the easiest place to publish a page)Allow people log-in using email and password and post new timers.
@nelsonic I was reviewing the Vagrantfile to understand what the basic setup was and the following URL was commented out: https://gist.github.com/wingdspur/2026107
as the explanation for sudo apt-get install openjdk-7-jre-headless -y
.
I would suggest swapping it out for: #OpenJDK Java runtime http://packages.ubuntu.com/precise/openjdk-7-jre-headless
I'm not a huge fan of the ephemeral nature of Gitter.
Its easy to lose a thread of conversation about a specific topic I much prefer to use issues where the thread of discussion is clear.
But... I do like:
Some services require a password of a minimum length.
We could set ours very low like (e.g: 4 chars - which is easy to remember but NOT very secure...)
Or require 8 characters. I'm asking because I'm setting up password validation in the API and want to check if others have views....
Are there any Microformats which apply to what we are doing?
Reliability of our time is crucial.
We will allow clients to send us the st (start time) they want the timer to start (from their device)
this allows them to set the time they think the task/activity started (i.e. retrospectively set a start-time...)
But we will also store a ct (created time) which cannot be changed and provides an audit for the person to know when they actually started the timer.
To this end, I propose using the https://github.com/hueniverse/sntp module to get "real" time from a Network Time Protocol (NTP) server.
A google search for time tracking app
yields "about" _108 Million results_
Widening the search to just Track Time yields _1.36 Billion results_:
Fast Company lists a few of "best" time tracking apps:
http://www.fastcompany.com/3024249/10-time-tracking-apps-that-will-make-you-more-productive-in-2014
If the "problem" of time/activity tracking has been "solved" by so many others,
_WHY_ should we "_re-invent the wheel_" ...?
We are not going to use couch. Tidy the Readme to reflect it.
Replace with link to: https://github.com/nelsonic/learn-api-design
@iteles I know you have some experience of using IFTTT
Once our API is live (MVP), should we consider how to make it available for use in IFTTT?
_or_...
Can we make our reminder component as simple as creating an IFTTT recipe? (UI)
For anyone unfamiliar with this, see: https://computers.tutsplus.com/tutorials/how-to-automate-anything-with-ifttt--cms-20537
https://addons.heroku.com/?q=elasticsearch
I'm currently favouring https://addons.heroku.com/foundelasticsearch
see: https://www.found.no/pricing/
but their "entry" level price is $40/month (no free tier!)
Whereas https://addons.heroku.com/searchbox has a free entry-level and replication/backup from $9 up.
As the title suggests. ๐
Using an auto incrementing _integer_ for each person works well when using a single SQL database. But given that is not the case for us, should we use a UUID?
When defining our Activity Model we can be _verbose_:
{
"PersonId":"string",
"ActivityType":"string",
"Description":"string",
"StartTime":"timestamp",
"EndTime": "timestamp"
}
_OR_ we can be _concise_:
{
"pid":"string",
"atype":"string",
"desc":"string",
"st":"timestamp",
"et": "timestamp"
}
The first option is descriptive and immediately clear.
The second requires "translation" for new people but is much less to type when actually building and consumes less bandwidth when sending data to/from the client/apps.
Which do we _prefer_? @iteles @NataliaLKB @besarthoxhaj @izaakrogan
When a person registers to use the service, should they be automatically logged in?
Or should they have to verify their email address first? see: #41
@NataliaLKB @iteles maybe this is one of the things we can bring up on our next work-day?
I'm not a fan of how hapi-auth-basic
requires username & password to be sent to the server as:
{ authorisation : 'Basic ' + (new Buffer(username + ':' + password, 'utf8')).toString('base64') }
i.e. the front-end app has to base64 encode the un+:+pw and send it in the auth header.
see: http://git.io/xdjk
I would propose we _fork_ the module and create a second option:
payload: {
email: "[email protected]",
password: "5up3r53cr3t54uc3!"
}
Thereby allowing people to send the authentication POST request to /login with either the auth header _or_ a form payload.
Do not require the reply.headers.authorization to be set on _every_ response.
_Note: request.headers.authorization is still _required on _request_ to private urls.
At the moment everything is _Public_ by Default.
Should we sketch out a user permissions system?
@iteles @NataliaLKB when do you have 20 mins?
We need to find a good alpha name for our MVP. It doesn't need to be the final name and it doesn't need to be a stroke of genius, but we need something that we can refer to other than 'the time app'.
We considered something super simple and just descriptive but really, the app is more than just a timer - it's more of a time tracker - and it would be much better to have something that:
Any thoughts?
I think it makes sense to check for user-agent consistency.
But, Should we be checking for IP address consistency?
(this might be an issue for a mobile device which will change networks...
do we want to force people to re-authenticate just because they changed cell towers...?)
To be reviewed at the 6 month mark.
There is a certain magic to analog productivity. Good old pen and paper.
It might be the feeling of the textured paper at our fingertips or the immediacy of putting pen to paper without having to hit the on button on our phone and swipe to get into it. It might just be that we are nostalgic for the pen in our hands or the sight of our own handwriting.
Understanding the beauty of paper and seeing if we can bring it to the digital world in a way that enhances the experience is probably worth looking into. The key would be to see this investigation as an opportunity and not a constraint or requirement.
Discussed in this closed pull request.
Image credit: http://shaycochrane.com
Should we use Redis for session storage or use ES for everything?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.