Wednesday, June 5, 2019

Pushing the boundaries of efficiency. How I enhanced the capabilities of a 15 button macro mouse: from 75 possible macro outputs to almost 2 million.

My mouse has 15 extra buttons that I use to improve efficiency. Using the software that came with the mouse, you are able to assign a key (or combination of keys) to each mouse button. For example, in the case of a debugger, having separate mouse buttons for: step into, step over, and step out can be really nice. They also let you make up to 5 different profiles that you can switch between manually through the software. So with 5 different profiles and 15 buttons per profile, you have 5 * 15 = 75 possible keyboard shortcuts you can assign.




But I felt like this could be pushed further. I also learned that a major drawback to this mouse is that it doesn't allow you to create a separate configuration for each Windows process which would switch automatically based on which process has focus. It's not just this specific mouse/software though, the higher-end mice I looked up also lack this capability, which would be a huge improvement.

Meet AutoHotkey:
AutoHotkey is a free, open-source scripting language for Windows, providing easy keyboard shortcuts, fast macro-creation and software automation, allowing the automation of repetitive tasks in any Windows application. User interfaces can easily be extended or modified by AutoHotkey (source).

This became my solution! With AutoHotkey being a language that facilitates macro creation, a whole world of possibilities for enhancing efficiency opens up. Using AutoHotkey, it is possible to assign each button of a macro mouse different keyboard shortcuts/macros depending on the current Windows process that has focus. You don't have to do any manual profile switching either. When you press the macro mouse button, the input is sent to AutoHotkey which automatically checks what the current process is, and then outputs the associated keystroke for that application via an if statement. This method has effectively allowed me to bypass the 5 separate profiles constraint of the mouse software, and the tediousness of having to manually switch between them.




My next great improvement involves multiplying the number of possible combinations to insane amounts through the clever use of modifier keys. Windows keyboards have 4 modifier keys: CTRL, ALT, SHIFT, and the WINDOWS KEY. The beauty of modifier keys is the multiplication effect they have on available combinations. For example, looking at just one mouse button, you can make it output 4 different keyboard shortcuts/macros through the use of modifier keys. If you assign F9 to the mouse button, then you can connect it to macros for: CTRL+F9, ALT+F9, SHIFT+F9, WINDOWS+F9. Just hold down that modifier key when you press the mouse button. What's even better is that AutoHotkey allows you to differentiate between the modifier keys on the left side of the keyboard and the right side. So (left CTRL)+F9 and (right CTRL)+F9 can be used for different macros. Now, instead of just 4 modifiers to pick from, we actually have 8 separate modifiers that can be used together to form unique combinations. Just from modifiers alone, we now have 8 factorial combinations available (8! = 40230).

15 buttons * (8 * 7 * 6 * 5 * 4 * 3 * 2 * 1) modifier combinations = 604,800 available macros per Windows process 

I could have stopped there, but I had already come up with another multiplication factor in the brainstorming stage. My final idea I implemented (for now...) is allowing AutoHotkey to differentiate between 3 types of button presses for each mouse button: regular button press, long button press, double button press. For example, if you press a certain mouse button for 1 second, it triggers the macro associated with the long button press. But if you press that button for 0.5 seconds, it triggers the macro associated with the regular button press. This creates a further multiplication factor of 3 to our previous number:

604,800 available macros * 3 new custom mouse modifiers = 1,814,400 available macros per Windows process.

Wow! I went from 75 total available combinations (without the power of process specific macros), to almost 2 million available combinations per process! Integrating my mouse software with AutoHotkey, the only thing constraining me now is my creativity, which is exactly what I wanted. I know this opens me up to more combinations than I can humanly remember, but this was more a test to see how far I could take this and also to learn how to use macros most effectively. This endeavour has brought me to AutoHotkey, which has made my macro capabilities on Windows so much more powerful. Here are the main results of this endeavour:

  • Process specific macros that are automatically triggered based on the current process focus.
  • 40,320 additional macros from modifiers 
  • 3 new custom mouse modifiers: long press, short press, and regular press options for each button 
  • Bottom line: 15 buttons * 40,320 keyboard modifier combinations * 3 mouse modifiers = 1,814,400 available macros per Windows process

Friday, April 19, 2019

My Multi Monitor Productivity Setup



Years back, I preferred laptops over desktops for the mobility factor. However, I began to feel like there may be a subtle trade-off between mobility and productivity when it comes to laptops versus desktops. For example, when coding, I could have my IDE taking up half my screen, with code documentation on the other half. But what if I was coding a function that required me to look up several separate areas of the code documentation? Well, I would either have to:
  1. split the right side of my screen in half so that I could cram a 2nd documentation window on that side, allowing me to read two sections at a time.
  2. look up and read each area of the documentation one at a time,
The problem with #1 is that you have to shrink the each of the 2 code documentation windows down to 25% of your screen. Not only does this greatly reduce your reading area, but sometimes it doesn't even work because the website's HTML/CSS causes the text to be unreadable at that window size. Another limiting factor is that you can only have 2 documentation windows open at once, which is still somewhat limiting.

The problem with #2 comes from the "context-switching" of the human brain:
To perform a mentally challenging task, such as programming at the optimal level, one needs to reach a state of flow, where complete focus is given to one activity (source). A state of flow (also known as being in the zone) is when a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does, and a resulting loss in one's sense of space and time (source)
I have come to understand that this state of flow is so crucial to productivity. When you're writing code, having to continuously stop, look up a separate part of the documentation, and then write code again can be an obstacle from reaching that state of flow. Virtual desktops can help reduce context-switching but they still don't handle it the way multiple monitors do, which provide much more potential to see everything you need to see at once. With multiple monitors, you instantly have more freedom to carry out your workflow.

Coding often involves having to check the documentation for a smaller set of key functions that are frequently used. It is very helpful to just have these open for a quick glance when you need to. Outside of those key functions tend to be many other "peripheral" functions that need to be looked up. This is my current setup and how I take these things into account.
  1. IDE: One horizontal screen dedicated to the IDE
  2. One vertical screen with 3 windows of key areas of the documentation. These windows stay constant for longer, because there are a smaller number of key functions and they're used more frequently.
  3. One screen with 3 windows of 3 peripheral functions in documentation. These windows change more often because there are more peripheral functions than key functions.


Minimizing the number of times I have to stop to look up code documentation has been really effective in reaching and sustaining the coveted state of flow. Here, the example I've given for is my usage with an IDE and code documentation. However, this has greatly improved any workflow I find myself doing. I strongly believe a multi-monitor setup has the potential for great impact in almost any workflow. With more screen real estate comes more flexibility.