Today I am really excited to announce that Nikhil Ramesh are launching something that we have been working on recently over the past couple of months – Muhnee.
Muhnee is a really simple and exciting way to help you manage your money. A lot of money management and budgeting apps are complex, requiring you to create ‘savings accounts’ , and are not really mobile friendly.
The goal of Muhnee is to:
To simplify the accounting and consolidation of financial matters through the analysis of past and present transactions and the establishment of future transactional patterns for the everyday, average customer
Muhnee Mission Statement
We wanted to make a simple and easy to use app where the mobile (and other IoT devices) allows you to track your expenses and income on the go.
Whilst the more advanced web platform helps you analyze and allow you to report off your expenses.
In addition, Muhnee will help you manage your stocks portfolio (which will come in later iterations). And for the short-term traders out there, Muhnee will tell you your returns based off your trades – profit, losses and even capital gains.
FYI, Muhnee is still in its early days of its development, we just wanted it to get it off the ground before our lives got more hectic (especially mine). So please do provide us feedback and try it out today!
Like many developers out there, Visual Studio Code (VSCode) is now my go to editor for almost everything (with the exception for Android Studio (for Android) and IntelliJ IDEA (for Java)). I really like customising my VSCode, so that it is easier for me to develop on.
There’s a lot of shortcuts that I use on a day to day basis within VSCode, the ones that I use the most include:
⌘ (Command) + P
⌘ (Command) + Shift + P
^ (Control) + `
⌥ (Option) + Shift + (Up or Down arrow)
Duplicate current line up or down
⌥ (Option) + (Up or Down)
Move current line up or down
There’s a lot more shortcut keys that I use, but those are the most common ones. The VSCode team also has some awesome key binding posters that you can print out and stick near your desk (I used to print these out with macOS on one side and Windows on the other and stick it around the office).
There’s some neat settings that I always loved being enabled within my VSCode User Settings (globally).
The first one is Format on Save, with this enabled VSCode automatically formats the file you are working on, it picks up ESLint, TSLint and Prettier configs which is pretty neat.
The second one is the Terminal Font Family, if you customised ZSH like me, the default terminal sometimes doesn’t know what font to render your icons in your terminal in and you’ll end up with question marks in boxes.
The last one is Enable Commit Signing, this automatically uses the -S for your commits, (use this if you use GPG signing for your git commits!) and integrates nicely with VSCode’s inbuilt Git feature.
I always loved the customisability of VSCode with the community building many beautiful plugins (and language support!).
Excluding language based plugins such as C/C++, Dart, Python, etc. I usually add themes, formatters, and other tools that I use.
We all know that making apps is hard, but making the app easier to use is even harder — especially when you are working on it everyday it’s hard to gauge whether or not something is more easier to use. But, throughout the lifecycle of MonPlan, we have iteratively improved the design of our app to make it easier to use and look more ‘pretty’ to the eye.
More consistent design — similar looks have similar meanings.
This is quite straightforward, making your design more consistent throughout the app by following design principles. But components within the apps should have the same meaning.
Within our older unit cards, no-one understood what the colours meant, the full greyed out stated meant that a unit error has been breached. With the newer changes we broke the card down into 3 sections:
Faculty (Coded with 3–4 letters) with it’s faculty colour,
the main body describing the most important info: Unit Code, Unit Name and the amount of credit points
And the new action menu which is a dropdown — triggered by the extra icon. Allowed us to add making it easier to drag-n-drop the card or allowing select-n-drop in mobile. By also moving our delete, view unit information and move units, we not managed to make it mobile friendly, but also ensuring that we met WCAG AA 2.1 Accessibility Standards. It also meant that we prevent some dangerous actions too — at least we can prevent errors.
We also applied this principle to our teaching periods after successfully testing the card principle out there in the wild, the change was made around mid-2018. This also gave us the ability to add more user actions to the teaching periods such as marking periods as intermissions or going on exchange.
By moving key actions into a dropdown, we firstly can prevent users from making ‘dangerous’ actions, such as overloading, removing the teaching period and other key actions, but also make it more mobile accessible.
Displaying what is necessary to the user
Something that recently that has been worked on is the validation modal.
The problem here is that how do we are making it easier for the user to understand what rules they have breached and how to resolve it. We are also presenting unnecessary information to the user, but also making it hard to understand.
When the user first looks at this modal — they are bombarded with information, and there’s no summary.
First, lets do the following things:
Add a summary box, that describes what rules are we comparing against
Remove the expansion panels (as expansion panels within expansion panels is not as ‘clean’ and also makes it hard to understand what is going on.
Hide all the rules which have passed inside the details section as it is ‘unnecessary’ information.
So lets break up the details even further…we’ll break down the unit rules into different ‘cards’, which makes the grouping even cleaner and also change the language so that it’s more positive so from ‘Errors’ into ‘Requirements’.
So we’ve added back the expansion panels as the user can choose to read them or not, they can expand and hide as their wish.
We eventually moved away from the ‘Paper’ design to group the errors, into a singular box, with a dashed border to help group the elements.
Throughout the iterative release cycle, we have built up various concepts and tried and tested out concepts in the wild under user testing sessions. And remember to keep your users first, without your users your application will go nowhere.