Documentation and introduction to our first MVP testing

In this post, we will introduce you to the latest realization of timeNough in the year 2022: the minimum viable prototype of the enterprise software we will one day sell. A stable version has now been released after 1 month of development. It is available on timenough.com, anyone including you can access it and test it. If you would like to test, we recommend you to read this new content carefully and take it as documentation for your testing.

One client company as an example

Before beginning your tests, you need to understand the context we have envisioned for this MVP. Our prototype, called timeNough, is supposed to be a software that will let companies and employees track and measure billable activities more efficiently and more comfortably in the future, by reducing the number of screens and dashboards they need to deal with during a typical workday. This is quite a challenge in the employee monitoring software industry, where there are already major players like Toggl, Desktime, and RescueTime. Despite this, our unique selling proposition remains: less interface, better flow.

The scenario begins with a hypothetical enterprise called CoreNough LLC. This entity does not exist in real life, but the scenario depicts that its employees are users of our software timeNough. Everything will take place inside an imaginary context, so that you can imagine what it could be like if the company you’re working for became a client too.

An imagined twelve-member team

Then come the CoreNough employees. Each employee doesn’t exist in the real world either, they are personas, people that could be your colleagues or you but aren’t. We keep building this fictional and alternate reality with 12 employees. By pushing the exercise to 12, we intend to provide at the end 12 custom demo interfaces for our prototype, one per imagined employee, each of which will highlight a particular feature of our software MVP.

There will be only two fictitious employees in the beginning: a woman named Lara Bowen, acting as Chief Marketing Officer of CoreNough LLC, and a man named John Doeson, acting as Product Owner. This link provides a trombinoscope of the team. Two mailbox interfaces have been designed to let you access the emails of these two specimen employees as if they were themselves, with basic features like sending and receiving real email. We are not going to do mailboxes, they are not our prototype, but here, the idea is to test something related to them, that’s why they are so important.

In order to test timeNough’s first features, anybody will need a functioning email account because everything is about emails in this first MVP version. You can also use your own email address to conduct tests for staying within your own mailbox interface by following what we call a “whitelisting process”. The following page explains how you can become whitelisted and have your email address trusted by our systems.

A concept driven by email subaddressing

The question now should be: why do you need an email mailbox for testing a software and not a browser or any other medium? This is because the main features, the first ones you should test, are those that involve email. Interestingly, we do not call it “email” features, but “signal” features. What’s the reason? Due to the fact that timeNough will deal with signals in its first versions and in this MVP. Not only you can send signals via email, but you can also do so via SMS, the chat of your company, or Slack. The signal is viewed as a means to interact with our software, to steer it, to pilot it, to control it.

It’s the core idea here to test: how can a software hosted somewhere, with the mission of improving track tracking and time measurements, be controlled via email or SMS? That is what all of this is about. By using a real email address, you will receive and send some emails to timeNough, which will act in the background, ready to listen for signals and ready to respond. Hence, timeNough is not something palpable for you. You won’t touch it or see it; instead, you will just observe it in action, see how he behaves as you send signals through the interfaces of Lara Bowen and John Doeson. Subaddressing is a mechanism through which you can then communicate these signals.

Briefly, Lara and John use email addresses like l.bowen@corenough.com and j.doeson@corenough.com, as you have in your company, while our software, timeNough, has its own email address, one that is internal and proper to CoreNough LLC: b@corenough.com, same pattern. It is as if they are communicating with a colleague, someone inside CoreNough, but in fact it is a software, and things will be even more interesting with subaddressing.

When they send signals to b+in@corenough.com or b+out@corenough.com, they will be communicating with the same software, but because these are aliases, the signals are interpreted differently. We built seven aliases to b@corenough.com, which means we have seven different ways to interact with the same piece of code hidden behind one internal email account.

A total of eight debut features to test

Since you now understand that timeNough and its MVP are acting as a background program, and thanks to Lara and John’s email addresses or your own but whitelisted, you will be able to send signals to it and see what is going on, let’s discuss what happens next. In total, there are 8 events that can occur depending on the signals you send and test. Each event corresponds to a feature we have developed up to this point.

Please note that the two mailboxes of John and Lara already contain 10 emails, and that these messages cannot be deleted. We call them “permanent emails”, and these are wikis, additional key information to assist you in understanding the software faster while testing it. You don’t have to go to a separate interface or documentation page; everything you need is already in the mailbox. You can find more detailed and useful indications there, so please take the time to read them all.

A. Testing part 1/8

B. Testing part 2/8

D. Testing part 4/8

E. Testing part 5/8

F. Testing part 6/8

G. Testing part 7/8

H. Testing part 8/8

Testing involves whitelisting and preferences

As discussed in point 2, whitelisting is essential if you want to test the MVP with your own email address, not Lara Bowen’s or John Doeson’s. In the absence of some security rules, having two open email mailboxes that are free and open to the public can be dangerous. Anyone can use it unjustly, and use it to send real emails with prejudicial content. In addition to the hardening built in and by default, a simple communication restriction has been put in place: “only internal email addresses can communicate with the 8 preceding bots“. As a result, only Lara Bowen and her address l.bowen@corenough.com, and only John Doeson and his address j.doeson@corenough.com can send email signals to the bots whose addresses also end in @corenough.com, like a closed circuit. But this requires that you and the testers use interfaces like this one and this one, which isn’t convenient after a while.

Whitelisting comes into play to add an exception to that rule, your own email address will be exceptionally authorized to send and receive emails from the bots as an external trusted contact. It does not exempt you from following a fair use policy and testing the MVP without harming it or our systems. The same set of rules will apply when timeNough and these bots are deployed inside a client company in production, in which the bots and employees will exchange information in a 100% internal way, and no outsiders will be permitted to interact with or even know that the bot exists! There is one test for this whitelisting mechanism included in all the test case tables, which should be viewed as a security measure.

MVP preferences have been designed so that you can do 8 things properly while testing our software:

There is a form for that, but all you need to do is sign up with one of the major social networks in less than 2 minutes to enroll. Whitelisting and preferences are different mechanisms with different aims. Follow this link to be whitelisted. You should lands to an email in the John Doeson mailbox. To access the preferences form, the mechanism relies on a unique URL that contains each time the email address of the user, so in the case of John Doeson, the URL should be as follows: https://timenough.com/mvp/preferences/?user-id=j.doeson@corenough.com with the query parameter “user-id” mandatory and always present in the address bar.

If you become a timeNough prototype user with the email address user@example.com, the URL of your Preferences form will be: https://timenough.com/mvp/preferences/?user-id=user@example.com and that’s it. Through the service Auth0.com, we have installed an authentication system, so you will not be able to access the preferences form of your friends, i.e. if you have one friend using the timeNough with his email address user-2@example.com, it will not be possible to access his preferences form https://timenough.com/mvp/preferences/?user-id=user-2@example.com because it is protected via social networks sign-in or classic password sign-up, with a validation link sent by email. As before, the preferences form and whitelisting are also considered features of the MVP, that should be tested as part of it.

It’s one door to a world of possibilities

Following on from what has been said earlier, subaddressing is a native feature of timeNough that lets us have an unlimited number of possible aliases, each with a unique purpose. So far, just 8 bot aliases have been developed in order to meet the scope of this MVP, but based on client company demand and needs, you can imagine a bot alias for tasks, projects, missions, training, event planning, annual evaluation, payment for the lunch or a team gift, process for updating contract terms or for instance starting salary negotiations, based on the delays and duration of the contract. It opens a door to a lot of possibilities when after a while, users get accostumated to the mechanism, sending signals becomes an automation even if it implies to manually send the signals.

There are no limits to what you can do with automation services like Zapier and IFTTT. Once you understand what triggers an email or a SMS, you can easily integrate that action into a bigger suite of actions with a higher level of customization. In this kind of third-party service, you can sync into one place multiple accounts you have, like your Twitter account or Facebook account, your Gmail mailbox, or a smart home service, and when something happens in one of these external platforms, like a new specific tweet or a new specific post, you can program a trigger mechanism that will send a specific email to a specific recipient. It may be one of the 8 timeNough bots…

Any chain of events can be set up, and these bots can be involved at some point – depending on your planning. Automaton and later IoT are clear next-door topics for this MVP, but we will discuss that in a subsequent article.

Thanks for taking the time to read this documentation. Please feel free to share your feedback and comments below or by joining one of these 3 online places where we are actively present, available, and reachable: Slack, Github, and Calendly.