LifeO’Meter playground app.
persP is approaching the public beta stage really fast now. We have changed so many things, in so many ways over the last 9 months, that I think it’s about time to show it working.
Since you’ll not be able to use the tool just yet, rather than a proper tutorial, I think we must call this article, and its videos, a behind the scenes of the project.
For us, this is going to be a first, in many different levels:
- It will be the first time we’ll show publicly the beta version of persP.
- It‘s my first complete behind the scenes ever and also, the first persP’s complete tutorial (kind of).
- It’s also be the first time I spoke in a video, in english. I’m truly sorry for that. :) Depending on how it goes, it could very well be the last one.
In this project I’ll not dive into areas like responsiveness, animation, publishing, sharing, languages, multiuser support … Those will be key points for future behind the scenes. Please understand that the link that I’m providing here is the live preview of the project. Not the final published version. Hence, HTML and CSS are not optimized in any way.
It took me 35 minutes (for real) to create the web app from the empty project to the final.
I split the behind the scenes into a series of 5 videos ranging from 3 to 4 minutes each. I’ve added the corresponding video to the top of each section below.
We’re currently looking for a small group of private beta testers. If you are interested, please DM in twitter.
Why the app?
I designed the app for three main reasons:
- First We needed an app small, capable and complex enough to be created from scratch in about 30 minutes. It also showcases several of the new capabilities that we have developed in persP beta.
- Second, it illustrates how a typical persP workflow is.
- Last but no least, It clearly states that I have to change some very bad habits in my life ;P
Life O’Meter
LOM is a really small playground app. It displays how shitty my life’s balance is, regarding work and personal time, specially these latest days that we are pushing really hard on the beta.
It displays the number of hours that I worked on any given day, along with the hours I spent just hanging around , sleeping or doing doing household chores, preparing meals, shopping etc.
It finally gives me a score between 1–10, which is just awful most of the days.
My activity data is served by a PHP file. FYI the data is real. I update it everyday. The app connects to it and binds the read data to the internal components to update them.
If you are interested the in the PHP file, down below, in the Data section, I provided some endpoints for you to try it in the browser.
Now let me recap some of the key points of the process:
Design
Even with nothing on the screen yet, not even slides, I defined the design system: Fonts and primary colors. It’s a really small project, but since we are going to use colors in a very specific way, I think it pays off.
Nothing too fancy nor too complex on the design part. Just some arcs, some texts, some gradients … and some alignment and distribution processes.
I’m not going to spend time commenting on the process here. As you can infer from the video, it works pretty much like every other design software out there. There shouldn’t be any learning curve at all or just a really small one.
Maybe the most noticeable thing is the context menu. We use it as a shortcut for the most common interactions that you deal with in a daily basis. I’m specially proud of it.
Components
I created 4 different components, using the elements I designed before (we call them actors). From top to bottom:
- The date component. It displays the date of the data being displayed.
- Main component. It displays the score and the circular graph along with the next and previous arrows.
- The histogram, where we display hour by hour the activity of the current date.
- Statistics. The detail progress bar per activity: sleep, work, personal.
After the components are created, I defined their taxonomy . Think of taxonomy as a special CMS that creates an interface for the component’s override panel.
I’ll not try to explain taxonomy here, it will be too long. As someone once said, one video worths a thousand words. Please check it out in the video.
I added controls for color, arc length, text and even text colors. Take a look at the detailed progress bar override interface (02:37). It still amazes me how simple is to create such a complex thing. If you were to design this component alone, it’d take you no more than 5 minutes including the taxonomy definition. How much time do you think it will take in a traditional approach?
Data
We call persP’s data management, scriBe. You can access it by clicking on the data Tab.
At the time of this writing, we can actually load data from JSON files (local or remote), any kind of API’s or external CGI files (php) and websocket connections. SQL connections are on the pipeline as well as CSV and XML files. They’ll be available on the release date. We’ve included buttons on the scriBe interface for unsplash and random user APIs. When pressed, they create the connections and endpoint structures for them with just one click.
Just for this project We have developed a really simple API. Can we call API just a single PHP file?. I don’t know. Anyway, It has several accessible methods, but we are going to use just 3 of them:
- ?api&get¤t (details)
OBJECT: it returns the current date info - ?api&get¤t&data (data)
OBJECT: It returns per hour activity for the current date. - ?api&get&stats (stats)
ARRAY: It returns the current date statistics per category, grouped in a variable called ‘results’
Configure the API data inside persP
Connected data inside persP is structured into connections that contain endpoints, whose data can be organized in different views.
You can establish refresh intervals for any data you connect, and you also can decide if you want to cache the data you just imported.
If the data is not cached, it will be updated whenever you load the project, do a preview, the refresh interval is activated (even inside the editor) or when refreshAPI or refreshConnection actions are invoked.
Socket connections will refresh the moment the socket info arrives.
Connections
I created a new external connection by just naming it and adding its url: https://block6.persp.info/upload/lifeometer.php
Endpoints
I added the three endpoints described above:
- Details
- Data
- Stats
To create an endpoint, just enter the name and the url parameters. Then, click on the rebuild button. persP will try to establish a first connection to the API. If there is any, it’ll bring the data, guess a scheme and create a table for it.
You can review the imported data by clicking on the table button.
End points have many more controls, including the ability to create views, adjust schemes … . But again, this is scope for a future Tutorial.
Data binding
Once we get pointers to the external data (our tables) it’s time to do something productive with them.
Before going forward, three important tidbits:
- In persP, every component creates its own table in the data section, although by default, that table is not visible. You have to manually make it visible.
- The scheme of that table is defined by the component’s taxonomy.
- And every instance of that component, becomes a row on the component’s table.
That gives us an incredible amount of flexibility. I.e, you can point any instance to another’s one data. You can have several instances pointing to the same row: if you update that data, every instance connected to it will update instantly. And … you can bind one instance to a complete different table.
This is huge, because now we can link any instance to any external data source, as long as it’s been properly defined in scriBe. And that’s exactly what I’m going to do right now.
By clicking on the Data Src tab on the overrides panel, we can choose from the dropdown the new data source. Once selected, It’s time to open the bind panel, by clicking on the bind button.
In this screen we will connect (bind) properties between the schemes: on the left side you have the table’s scheme and on the right side you’ll find the component’s scheme. On the editor side you’ll find the number of rows of the table and on top of everything you’ll find a view of the instance.
As you start connecting properties (by dragging from the circle), you’ll see how the instance updates in real time with the new values. By clicking on the right side data rows, you’ll se how the instance updates with the new values.
You can connect one table’s property to multiple properties on the component, but not the other way around.
You can apply that very same mapping (binding) to every instance of that component too.
And that’s it. What do you think?
Actions
Think of actions as a way to define really complex interactions inside persP without any code. We have a vocabulary of over 20 different actions right now. We have actions that show/hide elements, create on/off states, change CSS rules, timer, intervals, … We are adding more actions every week. FYI, the very first version of persP (that didn’t even have a name yet, circa 2014), had over 100 actions.
Actions can be connected to any event on any actor (mousedown, mouseup, mousemove, mouseover, click, longpress, …) or slide (page load, scroll, resize, sensors …) and will be grouped in functions that can be reused anywhere.
Why actions instead of simple code? Well, there are many reasons, but I’ll give you at least three:
- They are way easier to setup and use by non experienced users.
- We control exactly what’s needed for each action,
- Our actions are not tied to any particular language, so we can export them to any language we want (think about that for a moment)
For this particular project We only need to use 2 actions. The first one [AJAX] makes an asynchronous call to change the current day and the second one [refreshAPI] refreshes the endpoints with the new date values.
These are the API calls I’m using on the AJAX actions:
- ?api&get&prevDay
It changes the current day to the day before the current one if possible. - ?api&get&nexDay
It changes the current day to the day after the current one if possible.
Since components are live linked to their tables (endpoint), each and every time the data is refreshed the components will update automagically.
Design system (ii)
Finally I show that every actor connected in any way to the design system is updated every time the design changes. I made really ugly changes in there. Design systems are really, really powerful. And as it’s said, with great power comes big responsibility, right? :) Undo, undo, undo …
Right now persP’s design Systems include Colors, fonts and Styles. In the near future we will add assets, components and actions to them.
Vídeos
Here you have grouped the links for every video.
The original raw recording, uncut, mistakes and errors included, runs for 35 minutes, from empty project to the final result. If you are interested, you can review it here, although it has no audio.
Epilogue
Thanks for stay so long here. I promised my self I’ll make this article short, but no avail. Too many things to say.
I’m really interested in your opinion, please leave your comments below and ask your questions. How does it look? Does it seem complex? Should I forget completely about doing any other video speaking in English?
And as I’ve already stated before, we are looking for testers for the private Beta. If you are interested, Please DM in twitter.
More news before the end of next week. :)
