For developers who visit this site, you might wonder exactly what enabling portability is going to bring to your project. Do users really care about this feature? Here are a few Use Cases that try to help make clear who cares and why.
Background
What is a Use Case? | What is Agile?
Use Case for portability
- As someone who ...
- Stores all their data on a cloud drive service (e.g. DropBox, Box.net, OneDrive, etc.)
- Uses a USB drive to store all their data
Additional Use Cases
- As someone who ...
- [Security] ... stores all their data inside an encrypted volume for security purposes (this could be a TrueCrypt, VeraCrypt, Windows VHD, etc), settings saved outside of that volume are a security/privacy issue. As such, I need settings to be saved to the local folder. I'd additionally like to avoid writing any program-related information outside of the application folder.
- [Multi-machine] ... synchronizes two computers across a network, having the settings saved to the local folder makes this much easier. While there are ways to do this that include the AppData and Registry, it's much simpler to keep things in the application folder.
- [Backup] ... expects my hard drive to fail at some point, I run frequent backups and don't wish to chase down all the little the settings files saved in AppData\Local, AppData\Roaming, ProgramData, Program Files, and a dozen other places.
Note that, as with the "multi-machine" example above, there are ways to do this that include AppData and the Registry but they generally are more complex. - [Cross-platform] ... uses Windows programs on Mac/Linux/Android/etc. via a tool like WINE/Crossover, I avoid programs that save settings to Registry, as they're sometimes not well understood by WINE/Crossover and cause issues. As such, saving to the local folder is ideal.
- [Software Quality Assurance] ... tests software, it's a lot easier to go through starting from a specific program state from backup. With standard software, I regularly have to uninstall, reboot, reinstall, and THEN test a program. If I make a mistake in the middle of the testing process, I'll have to do it all over again, which is a huge waste of time.
Self-contained portable programs don't have this issue. You can even have multiple versions of the same program on one computer so you can see where an issue appeared, which enables faster determination of where a given code change created an issue.
While installer testing is often still necessary, it's better to spend energy on something more likely to catch more bugs. - [Upgrade testing] ... needs to have software work reliably and effectively, I can easily test the upgrade process by copying my current program to another folder. I then perform an upgrade on the backup folder to see if it causes issues. I can then either re-run the upgrade on my original folder or just copy over the result. (Care of user vevy.)
- [Single user account] ... wants to have multiple versions of the same program with unique settings, I can just create a copy and make changes. The only way to achieve this with installed applications is with multiple user accounts and lots of effort to log in and out to get to a modified environment. (Care of user vevy.)
Some programs will even let you run multiple copies of the same program at the same time (usually referred to as "instances").
- [Security] ... stores all their data inside an encrypted volume for security purposes (this could be a TrueCrypt, VeraCrypt, Windows VHD, etc), settings saved outside of that volume are a security/privacy issue. As such, I need settings to be saved to the local folder. I'd additionally like to avoid writing any program-related information outside of the application folder.
- As someone who likes portable software (with features mentioned in above use cases) I also enjoy the ease of updating offered by the PortableApps format (PAF). That toolset allows me to set the extract folder to the destination and won't overwrite the contained files, since the PAF tool avoids overwriting the "settings" folder.
---
Related: Hashing use cases