I solved a problem I was having and decided to release the solution (wndw) to the public. Wndw is a free and open-source desktop application that shows a section of your desktop within a window, so you can share that section using the 'share window' feature in video calls. It took so much more work to do the steps around releasing wndw than it took to build it. I found maintaining momentum in the process was more important than striving for perfection.
Why do this?
There is a concept in marketing and entrepreneurship that goes something like:
If you think your product solves a real problem, it is your moral responsibility to try and get affected people to consider that option as a way to lessen their suffering
This was in the front of my mind when I was using a small piece of software I wrote for myself, designed to make it easier to share my ridiculous super ultra-wide screen during work meetings.
I had written the core of the app in about two hours, inspired by a fireship.io YouTube video (that is long out of date, the APIs shown in the video are all deprecated). I thought that others could use this, and I found a couple (1,2,3) of Reddit posts of people suffering from similar issues. I thought as an act of charity I would package up the software and distribute those who needed it.
What problem was I solving?
In apps such as Google Meet, Zoom, and Discord you can either share an application window or share your entire screen. If you have a monitor with an unconventional aspect ratio, if you try and share your screen the video feed becomes so small and compressed no one in the call can make out the details.
You might ask why not just share the relevant application window? I work in web development and very often I want to switch between sharing my code editor and showing a browser tab that has reflected the changes I have made. This isn't really feasible using the 'share window' feature as it's a 10-second, click-intensive process to change the active window. To make it easier to show many apps in your screencast while maintaining a readable aspect ratio for the call, I made wndw.
How does wndw solve this problem?
When you launch wdnw.app it creates a new window on your desktop where you can select the screen you want to share part of. The screen-share feed overflows the window, so you can resize the window and scroll on the x-axis so the part of the screen you want to share is focused. In your meeting software, you can then share that created window, and it will show the part of the screen that you selected. Perhaps a small video demonstration will make it more clear.
Using wndw, part of your screen at an aspect ratio and resolution you choose can be shared. This creates a space where you can drag relevant windows in and out, depending on what you want others in your call to see.
How does wndw work (technical description)
I use electron to interface with native operating system display capturing APIs. The Electron documentation is great for this feature. I display the video feed in an HTML <video> element that has 100% height and overflows the window in the x direction. The electron app is scaffolded using electron forge to make it easier to build for all platforms, I highly recommend this path if you're making a simple electron app.
That's it, it's incredibly simple but it works well and actually has good UX because you're up and running in so few clicks.
Getting ready for release
This is the part that took me by surprise the most. My internal prototype took me about 2 hours to write. Everything around getting ready for release took me closer to 30 hours in total. If I do another project like this I intend to time-track it to get the exact figures.
The functionality of the two above images is close to identical (the released version allowing the selection of exact aspect ratios) but it shows the steps that I felt had to be taken before letting the public have it.
These are the steps that I took, in the order I did them:
- Add the feature of showing a preview of the window you're sharing (I only had one monitor so it never mattered
- Add the ability to build the app for Windows, Mac and Linux (I spend 95% of my time on a mac so this never mattered to me)
- Find a product name and matching domain name
- Buy the domain name
- Decide on some very basic branding
- Add that branding within the app
- Create icons and convert them for every platform
- Design a landing page
- Build the landing page
- Venture into my VPS, learn how to host multiple domains on the same server and upload the landing page
- Generate SSL certificates for the website so they connect securely with https
- Upload my code to a public repository on Github
- Removing all my junk code from the code base (as it would become public and I wanted it readable so people could verify legitimacy & contribute if desired)
- Record a quick demonstration video
- Create readme files
- Test the app on Mac M1, Mac Intel and Windows
- Ask my friends to test the app on Mac M1, Mac Intel and Windows
- Build the app for the above platforms
- Research distribution methods of your free app and decide on Github releases as its free and the code is there any way
- Upload the releases for people to download and use
- Post on a couple of relevant subreddits about the product (in progress)
If that list seems quite long then it felt longer. What started as a fun weekend project ended up taking the best part of a month (slowed down by life stuff).
How do I feel about the release?
Mixed. I will break it down into positive and negative feelings.
I really admire digital artisans' 100rabbits. I always imagined in my head that if I was to release some software it would have the same strong sense of aesthetics and principles that their software has.
- Aesthetics - This branding/website for the app reflects the truth. It was rushed. I have excuses for this including a very hectic home/work life at the moment but I know in my heart it's not valid. I could have spent more time and care making the product a reflection of the styles I like.
- Principles - Electron is a very convenient but wasteful development platform. This simple app is 200MB on Mac and uses 100MB of RAM as it comes packaged with chromium. It is yet another layer of abstraction between the code and the hardware, decreasing efficiency - native code would solve this problem. It would be smaller filesize, faster, use less RAM, launch quicker and consume less energy.
- I actually finished the project. Many people start and drop hundreds of side projects without actually finishing any so I have pride that I got this done and out there. I decided to optimize for momentum, not spending too much time getting bogged down chasing perfection and it paid off. I mentioned above that not spending the time gives me a negative feeling, well it's true I'm conflicted but in general, I think that releasing this imperfect vision is better than giving up and releasing nothing.
- I think the product solves the problem well. It's simple to use and the UX is all I could hope for. Launch app - 1 click - go.
- I think the product will make the lives of a small subset of people just a little bit better. I have had some positive feedback already and some 'thanks for making it' and there is a chance it could spread in the ultra-wide community
The positive feeling that I finished something and released it overrides any negative feelings I have about the development process in general. Releasing this for free instead of trying to build a product to sell actually made me more likely to finish it, as I wasn't bogged down by value proposition, payment, etc.
I feel like I have done something that is good and even if it's a very small good I am proud and happy that I did it.