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:

1. When do we need to have this in the app by?
2. Do we build it or use an existing service?

• We could add a feedback button to every screen in some predetermined corner that opens a message box
• We could base the feedback box appearing based on shaking the phone
• We could use something like Instabug which feels a bit like a temporary 'quick fix'

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?

http://opensource.org/licenses

Should we use Redis for session storage or use ES for everything?

Here's one I made earlier: https://github.com/ideaq/hapi-auth-jwt2
Help very much appreciated with breaking it! ;-)

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

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.

• The Case for a Paper Planner
• Deep Habits | Working Analog

Discussed in this closed pull request.

Image credit: http://shaycochrane.com

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:

• the ability to @/all when asking a question to the group.
• better notification system than GitHub for mentions, new issues/PRs
• less intimidating for new people who might not want to create an "issue" and just want to chat...?

Related to: #42
given the speed (low latency) advantage of using Redis (in-memory) Caching, it makes sense for session tokens.

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.

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...?)

Allow people log-in using email and password and post new timers.

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.

At the moment everything is _Public_ by Default.
Should we sketch out a user permissions system?
@iteles @NataliaLKB when do you have 20 mins?

@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

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:

• Has some personality
• 1 or 2 syllables
• Simple
• Domain names are available (especially .com, .io or something equally 'standard')

Any thoughts?

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....

• http://lifehacker.com/5617074/your-password-should-be-at-least-12-random-characters-long-to-be-safe
• https://blog.agilebits.com/2013/08/31/how-long-should-my-passwords-be/
• https://www.owasp.org/index.php/Password_length_%26_complexity
• http://security.stackexchange.com/questions/10776/regulations-that-specify-password-length
• http://en.wikipedia.org/wiki/Password_policy
• http://en.wikipedia.org/wiki/Password_strength

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.

For example:

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.

If a person (or App accessing Time via API) has a _Valid Token_ the token should still be checked for the person's id and not allow random people posting a _new timer_ (or updating an existing timer) on behalf of someone else (for fun or malice...)
Related to:

• Permissions: #5
• Start timer: #12

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?

Todo

• Generate Privacy Policy
• Save it as a version-controlled html file in the project.
• Publish it on dwyl.com (the easiest place to publish a page)
• Update the App settings on Google Play: https://play.google.com/console/u/0/developers/7684502167734640710/app/4975183496784052219/app-content/privacy-policy

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/

Are there any Microformats which apply to what we are doing?

• http://microformats.org/wiki/Main_Page
• http://www.smashingmagazine.com/2007/05/04/microformats-what-they-are-and-how-to-use-them/

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?

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

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.

As the title suggests. 😉

Start a basic timer.

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

Replace with link to: https://github.com/nelsonic/learn-api-design

@NataliaLKB @iteles maybe this is one of the things we can bring up on our next work-day?

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.

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_" ...?

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 ? ]

• investigate https://gsuite.google.com/marketplace

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?

• http://en.wikipedia.org/wiki/Universally_unique_identifier
• http://www.ietf.org/rfc/rfc4122.txt

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.

@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

Moving the project to ideaQ means its easier to include people in the development.
But it means we need to update all the badges...

Some people will want:

• Show me a list of my running timers
• Automatically start a new timer when I open (_and/_or show list of existing)
• Automatically stop my most recent timer.

There will be other actions. But the question is: should we make this a thing?

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?

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.

I Love the Einstein quote:

but propose this one is more apt:

thoughts?
Do you know a better quote for time management?

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

Todo

• Capture our decision to use the word people to describe the human beings using our App(s) so that we never have to have the "Users" discussion again.
  • Add a "Who?" section to the 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.

Borrow from: https://github.com/nelsonic/esta/blob/master/.travis.yml

Remove hapi?

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

We are not going to use couch. Tidy the Readme to reflect it.

https://david-dm.org/nelsonic/time#info=dependencies&view=table

I'm not a fan of how Lab uses Domains for catching exceptions.
(domains are considered "Unstable" according to the node.js API ... )

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

Should we require people to confirm their email address by clicking a link we send to their email address?