This is the second update on Scifibot, my companion app for sci-fi fans. Things are finally starting to take shape, which is great and bad at the same time. It’s great because the app is coming together and I can actually see it working. The bad part is that I reached the 90% development mark, which means I have only 10% of work to go. Right?
If you have experience shipping any software that targets real users, you know the last 10% of the development actually represents 90% of the project. That’s the amazing development math, but it is true if you want to deliver a product with decent UX instead of a clunky pile of non-functional buttons. My last tasks regarding Scifibot have been almost exclusively focused on UX, like tweaking menus, adjusting buttons, creating visual feedbacks for actions, etc. It’s a boring task to me, but it needs to be done.
I also added some love to the title screen (the one showing the details of a movie/series). It’s now possible to see real ratings from IMDb, Metacritic and Rotten Tomatoes. I also decided to leave the reviewing of titles out of the app for now, because it will consume a significant amount of time to implement. I want this app out quickly, so it’s time to start dealing with feature creep.
Under the hood I worked on the synchronization code, which is responsible for updating the app’s database with new titles informed by the REST API. I designed both the API the and sync system to consume as little network resources as possible. The app will never ask the server about the full database, it will ask for modifications since a timestamp instead. It should prevent the download of already acquired info, cutting data transfer. I also implemented an “offline sync” procedure, which is used in case the app is updated via Google Play. Internally any new version of the app will be seen as new data to be sync’d, so I can actually update the catalog of titles using Google Play updates, if necessary.
Things got a bit complex after the sync system was in place, so I needed a way to trigger sync actions manually. I spent a few hours and created a settings screen. At the moment it has the bare minimum required for the app to run, like an option to enable/disable remote sync, allow device notifications, etc. I don’t plan to add much more options to that screen, but it is there (and already working) if needed.
Last but not least, I worked on the notification system. It will be responsible for informing the user about new content, especially info regarding titles the user is tracking/following. The gif on the side has a demonstration of the notification system showing two new titles that were added to the catalog recently.
At the moment my focus has been on fixing bugs. There is a very nasty one regarding dynamic screens and navigation. I thought I was using Framework7 in the wrong way, but it seems it is not my fault. It looks more and more like a bug on their side, but I will work around it. After this bug is fixed, I think the app reaches alpha status and I can start packaging and deploying it on real mobile devices. I’m looking forward to doing it!
I love scifi movies and series. There are plently of good (and not so good) titles out there to be seen, but it is really hard to find them or keep track of interesting things. If you are like me, you probably had spent a significant amount of your time 1) finding things and 2) making notes or equivalents to remember what to watch.
I would like to see a list of every scifi movie or series available with a clear indication if I had or not watched it yet. I want to see a cool movie/series and add it to a list I can come back to later. More importantly, I want to be informed about the titles I am interested on, e.g. receive a notification when an upcoming movie hits the theaters.
Filled with frustration of my current workflow to find/track things and inspired by the bright future described above, I decided to work on a mobile app. Its codenamed Scifibot. I have managed to work on it during the weekends and sometimes during the weeks at night.
This post is a dev log regarding my progress so far. I wanted to quickly finish this project, so I decided to stick with web technologies (HTML5/CSS/JS) on top of a runtime (e.g. Phonegap or similar). After spending some time reading about and testing a few mobile frameworks, I decided to go with Framework7. I had never heard of that before, but it is a full featured HTML framework for building iOS & Android apps. It is simple, efficient, elegant and easy to grasp.
After my first coding session (about 2 hours), I was able to put together a very simple app fully implemented on top of Google Material Design, which is a must for Android. That was impressive. I had used jQuery mobile in the past, but my progression at the time was not that good.
My development focus has been on creating the basic structure of the app, creating the screens and the flow among them. Here is an screenshot of the current state:
I had a few quirks regarding some aspects, such as the navigation bar and its buttons. It is probably because I am doing something wrong, but I will deal with that later. The plan is to move fast and reach a MVP, then iterate from that. As any good side project, feature creep has already took over, but I moved several of the non-essential features to the “Cool to have in the future” pile. The project should be safe for now :D
I want a functional app, so it should be fast and self-contained. As a consequence, no login will be required and no internet connection too. However, if the user wants to backup any saved things or make reviews, for instance, authentication will be required.
Here is a gif showing a bit of the app (it is alpha state and totally incomplete):
If you like scifi, stay tuned for my progress. This app will be available on Google Play in the near future, specially because I am tired of keeping track of movies/series to watch in an archaic way.
Since I started my PhD in September, 2015, I have been writing a lot of code. My research project contains its fair amount of theory, but it is significantly practical and applied science, so I need to write software to test things out.
A percentage of my coding was indeed targeted at creating original software that could do something related to my research. Another significant part, however, was about automation:
In my case, doing applied science means I need to iterate, test and evaluate a lot of things on a daily basis. I could do the analysis by hand, or by copying-and-pasting numbers back and forth in Excel. In the short term that works perfectly well, but things start to grow and become more and more error prone in the long run.
In February 2016 I conducted an experiment involving games, facial expressions and heart rate measurements. Each participant spent, on average, 25 minutes in a gaming session, which involved playing 3 different games (two coded from scratch by myself), resting and answering questionnaires. I could be there in the room, with a notebook frantically taking notes of things. Then I would need to transcribe all that information into a spreadsheet to perform further analysis. Again the chances of misplacing numbers here and there is very real (and dangerous), so I wrote a software to run the whole experiment for me.
During the development time, I even spent a few additional precious hours to create a very simple web interface, accessible from my mobile, to monitor the experiment. That was awesome! Even though I was not in the experiment room, I could just light up my phone and see what was happening. Was the participant playing game #2? Or maybe resting? I could enter the room at the precise moment the experiment was over.
Later on I needed to analyze all the data I collected. Solution? I wrote another piece of software to visualize the data (since everything was custom recorded):
A few months after the experiment, I started a paper about it. I needed several different chunks of data and reports, so I distilled several command line utilities (e.g. analyze and hr2db) that helped me obtain what I wanted. As a side note and honest advice, don’t write crappy and/or undocumented software just because you are the sole user (at the moment). Doing a PhD often involves switching contexts pretty frequently, so at times I only re-used (or coded again) a utility 2 months after its creation. Despite being the author of the tool, it is fair to say I remembered nothing about it after 2 months doing other things. The tool might as well be considered to be written by someone else.
That’s the reason why I tried my best to make the tools at least UX-acceptable with a minimum amount of documentation:
A few months ago, I had to analyze a database of 530 videos, all containing BDF files unsupported by my software. I needed only the HR from those BDF files. I found several different programs that could convert the files to me, but they required manual interaction with a GUI. Solution? I wrote BDFextractor to extract the HR from BDF files using the command line. Now I could run (another) little software on the database and export the HR from all those 530 files. Victory!
I have been writing lots of R code lately, to perform statistical analysis and plot some charts. I can confidently say I wrote more multi-use support software in the past year than I thought I would.
Writing that much software might be seen as a waste of time, after all there are plenty of solutions out there for virtually everything. Every move demands time, though, be it learning (or developing) a new tool. Time is an incredibly precious resource, so I always choose the option that better accounts for that. Every time I have to write a small tool, I remember the advice from an old saying about chopping off of a huge tree: if you have to do it, you better have the right tools and be sure they are as sharp as they could be. That’s a fact.
I am pleased to inform that version 1.1.0 of cvui is out! cvui is a simple UI lib built on top of OpenCV drawing primitives. Here is an image to show the new features:
This release is backward compatible, so users of the lib should be able to upgrade by just dropping the new files into their projects. There ara few bug fixes as well as some pretty cool new features.
One of the most annoying tasks when building UI is to calculate where each component should be placed on the screen. Version 1.1.0 brings a set of methods that abstract the process of positioning
components, so you don’t have to think about assigning a X and Y coordinate. Instead you just add components and cvui will place them as you go.
An example is the beginRow() function to start a group of elements. After beginRow() has been called, all subsequent component calls don’t have to specify
the frame where the component should be rendered nor its position. The position of the component will be automatically calculated by cvui based on the components within the group.
All components are placed side by side, from left to right. E.g.
Rows and columns can be nested, so you can create columns/rows within columns/rows as much as you want:
I am pretty happy with the new API and the possibilities it brings, specially because it means less code to achieve more things. That’s always a thing to celebrate =)
I have been working a lot with OpenCV and C++ lately. After spending a great amount of time waiting for things to compile (so I could see my changes), I decided to improve my workflow. I decided to make changes in runtime, so I could tweak things without the need to recompile the whole project.
I immediately faced a problem: how to quickly and easily create GUI with OpenCV. The OpenCV lib has complete support for Qt (which is great for UI creation), but you need to compile OpenCV with such Qt support. If you don’t like that (or you have OpenCV compiled without Qt), you can enable OpenGL and use any of the awesome GUI out there, e.g. imgui. If you decide for that, you add the OpenGL dependency to your (probably already complex) project.
I didn’t have Qt available and I didn’t want to use OpenGL, so I distilled cvui. cvui is a (very) simple UI lib built on top of OpenCV drawing primitives. All the rendering is made using OpenCV, by calling cv::rectangle(), for instance. Here is a picture of it working:
The API is heavily inspired by imgui. The calls are all C-like, so no classes, objects nor OOP. I have nothing against that, I just wanted an extremely simple way of creating UI for my application (one line written, one thing on the screen).
At the moment, the API includes a small set of components: button, checkbox, window and counter. I will probably add more components in the near future. For more information, visit the cvui repository on Github. The code is MIT licensed.