Applications. How do you organise yours?

Last night, I settled down with Risc User (June 1993 issue) and was interested to read Mike William’s method of organising his applications. He recommended organsing them alphabetically, across multiple directories. E.g. Apps-A-M, Apps-N-Z.

I currently install everything in Apps, with !PackMan adding its own sub-directories in this directory.

Would be interested in hearing your preferred methods. I imagine taking a Mike Williams-inspired approach would cause problems with !PackMan.

I am currently install everything in Apps

The development stuff goes in $.Coding.

Most common applications are put in $.Apps because that shows up in the Apps thingy. Less used stuff goes in subdirectories in $.Apps (which don’t appear in Apps). I’ve added Printers and PrintPDF to Apps.

Collisions with the way !PackMan works or with the RO5 standard disc image or with whatever R-Comp or CJE deliver as standard disc images with their preconfigured systems nowadays are unavoidable. !PackMan allows you to produce “links” to be put wherever you like, which mitigates some of the possible collisions.

I settled on using the standard image by whoever provides it (I have plain RO5 systems, ARMX6, Titanium, IYONIX, Risc PC, V-RPC…), because this makes upgrading easy. I add the stuff I want to use into “Programs” and the things I produce or work with into “Data” (which is the only subdir structure I regularly back up). Below these, I use a functional separation with sub-folders. As examples, the full version of SparkFS is in Programs.Archiver, while GhostScript/GView are in Programs.Graphics.View, and FTPc in Programs.Network.FTP.

The most-used programs additionally reside in AppDock for quick access without navigating through filer dirs (so filer windows are only open for the data I work with, not for applications I start), and I generally keep the Pinboard completely clean apart from “work in progress” stuff.

Alphabetical organization seems strange to me – I would need to remember every app name I may want to use, it is much easier to think “task-oriented” for me – if tomorrow someone writes a new FTP client, I will still find it inside Programs.Network.FTP, no matter how creatively it is named by its author.

But I guess it depends a lot on habits and also the number of applications you usually use.

it is much easier to think “task-oriented” for me

This.

It is essential if you have more than a dozen applications to categorise them by purpose. Why should I be staring at Moonfish when I’m trying to find Nettle?

[of course, this is spoken by somebody whose application names are either extremely functional (MoreKeys, Manga…) or highly eccentric (Auremia, Harinezumi…)]

The one thing I have a real “bee in my bonnet” about is sub-folders in Apps (as unfortunately favoured by packman etc). The reason I get so frustrated is because the Apps folder is a special one, introduced by Acorn with a very specific remit of mapping to the “Apps” icon on the iconbar.

One thing we always used to mock Windows for (right back to Win3, but still present) was creating a bizarre disconnect between its user interface with program groups such as “Programs” and where things were on your drive. Why have a structured hard drive if the user interface (OS) is going to ignore it?

Because of the way Acorn designed Apps icon on the iconbar, it doesn’t show the contents of sub-folders. Thus, if you use sub-folders in Apps on your hard drive to contain actualy programs / applications, it creates a disconnect between the two.

For example, if I, as a person giving tech support, ask someone to open “Apps”, they may open the iconbar version, or they may open the hard drive version. I really don’t want them to see completely different things!

As Rick says, sometimes there may be a good reason for “hiding” things in this manner, but in most instances it is essentially causing confusion for little/no benefit.

I appreciate that “add to apps” gets round this to some degree, but the sub-folders in Apps essentially force this, and encourage a behaviour that effectively breaks what Acorn were trying to do with the Apps folder in the first place.

I guess the real solution is some kind of “smarter” Apps icon/folder interaction. Of course, the tricky thing is figuring out what that would be, as I suspect every user would want something subtly different.

As Rick says, sometimes there may be a good reason for “hiding” things in this manner

Oh don’t get me wrong here. When I say that subdirectories don’t appear in Apps, it’s an observation rather than a compliment.

Used often apps: Apps → doubleclick
Less used apps: SDFS → Apps → folder → doubleclick

If Apps supported directories, it could be better organised and things all together. On systems with numerous different applications (namely any system people actually use), directories in Apps is a necessity otherwise it becomes a mess of jumbled up things.
There’s a part of me that wonders if I should just AddTinyDir $.Apps and call it quits for the useful things that Apps almost does…

was creating a bizarre disconnect between its user interface with program groups such as “Programs”

That’s only people who let apps install themselves into the Start menu and never bother to sort it out, leading to a start menu two or three columns long with everything all mixed up. It’s perfectly possible to organise the menu so there are submenus by category, but I’ve yet to see anybody do it. They just pin everything to the backdrop, perhaps in tacit acknowledgement to the fact that their Start menu is such a mess that they can’t find anything.

Of course, the tricky thing is figuring out what that would be,

That’s easy. Recreate whatever is in $.Apps (as it does now) and have AddApp to poke in applications from other locations (as I do with Printers and some of the stuff in Utilities).
Do not automatically insert the ROM applications, add them with AddApp in a boot script (so they can be put into directories if desired, like Draw and Paint in a “Graphics” directory along with ArtWorks and PhotoDesk…), or omit them altogether. Customisation is the key here. Do that, and people can set it up as they wish.

and I generally keep the Pinboard completely clean apart from “work in progress” stuff.

Ditto. My coding environment is an obey file that initiates the DDE, sets up Zap (in case ZapFonts not seen), opens some directories upper left and places some important code directories, header files, and other stuff on the pinboard lower left. DeskLib opens its header files in a directory aligned to the right. Work area? All the middle. ;-)
What is pinned where depends upon what I’m working on. There are no apps with permanent residence. This isn’t Windows!

For example, if I, as a person giving tech support, ask someone to open “Apps”, they may open the iconbar version, or they may open the hard drive version.

You must specify clearly which one, and ask to confirm. Never leave any chance for ambiguities. I once asked a person of the computer that wasn’t working was plugged in. It was. I should have asked if it was plugged in at both ends.
As tech support you need to think ahead and think of not only what you want your user to do, but also ways in which they can cock it up… And yes, it’s often a thankless task akin to a twenty first century Sisyphus. At least RISC OS is fairly simple. Imagine remote support for something like XP (etc) where you need services.msc and a registry tweak, and a user that barely knows what a command line is… Yikes.

The one thing I have a real “bee in my bonnet” about is sub-folders in Apps (as unfortunately favoured by packman etc). The reason I get so frustrated is because the Apps folder is a special one, introduced by Acorn with a very specific remit of mapping to the “Apps” icon on the iconbar.

I find this useful as it can include “back-ups”, things I am not entirely sure of the legality of, and stuff which may or may not potentially useful.

For example, I store my previous version of StrongEd there, which may or may not be essential to revert to at a later date!

That’s only people who let apps install themselves into the Start menu and never bother to sort it out

To be fair, there are braindead installers out there that only add to the confusion. VMware, for example, when doing a minor update (such as from 7.0.1 to 7.0.2) will ask whether to create a Start entry. I already had one, so I said no. It took this as licence to delete the existing one.

That’s only people who let apps install themselves into the Start menu and never bother to sort it out

Are we talking RISC OS here – which doesn’t have a Start menu, or some other obscure OS which doesn’t concern us here?

or some other obscure OS which doesn’t concern us here?

When one draws comparisons between the way our system does it and the way another does it, it is generally useful to attempt to understand the benefits and shortcomings of the other system to avoid making the same sorts of mistakes. In this regard, things from afar can concern us.

Oh, and by the way, I think you’ll find that if you pull your head out of the sand, the appellation “obscure” is more appropriately applied closer to home.
It is worth pointing out that XP generated 500 licences in its first five years, over twice that in its lifetime, and probably twice that if you count installations with all the pirate and clone and duplicates (one CD multiple machines). And how many copies of RISC OS did Acorn ship in their entire history? Hey, include Arthur too. In fact, you know, for the hell of it, include the 6502 range. Indeed everything Acorn ever created versus one single version of an “obscure” operating system.
Have I made the point yet, or should I drop an anvil too?

I put things in the Apps directory. Some just live in there. Others in subdirectories based off category, and possibly more subdirectories based on specific function. I barely ever use “Apps” on the Iconbar, but if there are things I want in there I make sure those directories are added to “Apps” too.

Putting them in alphabetical order is a horrific idea, at least to me. I’d never be able to find anything because I find things by function, not a name which I probably won’t remember.

I currently install everything in Apps, with !PackMan adding its own sub-directories in this directory.

If I download an update to a piece of software (e.g. ArtWorks) then I create a directory $.Apps.ArtWorks.Ver145 and put the zip file there. I copy the old application directory to $.Apps.ArtWorks.Ver144.!ArtWorks and upgrade the old application. I do the same for stuff in the Utilities directory.

This means I can easily run an older version of the application if I need to but only the latest versions appear in Resources.Apps (and identically in $.Apps with the sub-directories out of view further down the screen).

My criterion for whether something should go in Apps or Utilities is a simple one. If I only ever want the application to start when I double-click on a file it will run then Utilities is fine. If I want to open the application to create something then it needs to be in Apps.

I find it extremely frustrating if, just because filer windows are being displayed in date order, the Resources.Apps window shows applications in some obscure order unrelated to the datestamp of the directory but linked to whether the is a RunImage file inside it!

I have directories in $ , like one for text apps and so on.

This topic is fascinating and frustrating. I hope nobody minds if I enlarge its scope slightly from applications to any sort of file. The whole problem with filing, with any database in fact, is that one wants to sort and display objects by different attributes, and sometimes simultaneously. Take emails, for example. I leave it to my email application, Messenger Pro, to keep a record of what I have sent. I delete most of what I receive and store what I want to keep, organized mostly by sender – I have separate directories for each sender in a directory called Letters. In some cases I deviate from this rule: Fred Graute’s emails I store in a directory devoted to StrongED, and Jim Nagel’s in a directory Work.Articles.Archive, for example.

A particular bee in my bonnet is that filing systems are frequently under-appreciated. The wheel gets re-invented by each browser with its own system of bookmarks/favourites, or whatever it chooses to call it. I prefer to use the URL filetype. The filing system is not sufficiently flexible and extensible to do everything that a bookmark system can do, alas (which I guess is why the wheel has to be reinvented in the first place), but at least it is browser-neutral.

The smoke and fire over packaging of applications highlights the fact that our filing systems are complicated pieces of real estate, with different owners laying claims to different ghettoes. Some belong to the operating system, some to the owner, some to software authors, and so on. Unix provides soft links for palliating the problem of getting at objects that need to appear in different categories at once. I have a small utility !Links that lets you create something that partially realizes soft links – you CTRL-drag an object to where you want a link to it to reside. It is particularly useful for shadowing directories.

Over the years I have used many different ways of organizing my files, so that by now it is a complete muddle. The need to keep backups means that it is hard to keep the different muddles from interfering with each other, and often I forget where I put something. The multiplicity of USB ports provided by the Raspberry Pi, and, if necessary, my 7-port hub,
make it sensible to keep stuff on different memory sticks.

Now that I have another Raspberry Pi running Linux I am aware how horrendous filing systems can be – especially as every different Linux distribution has its own conventions.

GUIs for filing systems are often not very smart. Why display masses of identical icons for 100 files called foo_00, … , foo_99, for example? Would not a rolodex icon with a number-selector be better in this case?
It goes to show that interface designers do not stop to think what they are doing, but blindly apply old, and perhaps inappropriate, solutions.

System variables that name filepaths, and the Obey$Dir trick, are very useful, but introduce insecurities. To a certain extent they help to keep separate the owner’s organization from that of the OS.

Collisions with the way !PackMan works or with the RO5 standard disc image or with whatever R-Comp or CJE deliver as standard disc images with their preconfigured systems nowadays are unavoidable. !PackMan allows you to produce “links” to be put wherever you like, which mitigates some of the possible collisions.

Just a quick reminder, PackMan has for a long time allowed you to drag most the components_*_ in a Package to wherever you like on your disc so you no longer need to use “links” if you don’t want to. The install directory it gives is just a default, so if you’re OK with where it installs things you can just click OK to install.

It has always allowed the default install directories to be configured so you can even change these defaults.

* Since December 2013 (I think), but there are still some older packages that haven’t been updated for this

Because of the way Acorn designed Apps icon on the iconbar, it doesn’t show the contents of sub-folders.

Could a use case of this be the organisation of larger apps like !Easiwriter, which has lots of supporting documents, tutorials and programs? I could pull the !Easiwriter application out of its parent (non-pling) directory into Apps, so it’s accessible for the iconbar App icon, but also keep the rest of the supporting files in a normal directory in Apps, knowing that everything is gathered in the same place, and accessible via SDFS::Apps should I need it?

That’s only people who let apps install themselves into the Start menu and never bother to sort it out, leading to a start menu two or three columns long with everything all mixed up.

When I’m working on Windows, I don’t tend to worry about organising things. I just search for the application name in the Start menu’s search box. I expect Windows to offer me my most commonly used applications in the Start menu too.

This is something I do now wilt email too. I’ve grown to trust search over my organisational ability. In a way, Mike William’s A-Z system is closer to this philosophy…”I know the application I want – and threrefore I know it’s in this directory”. Not saying I’m advocating this though!

When I’m working on Windows, I don’t tend to worry about organising things.

Yeah, that’s the road to the sort of situation one of our staff described with a user that had regular logon problems and a sympathetic person¹ looked at it to gather info for passing on to the dreaded techies.
Base problem: Profile too large.
Root cause: Lack of user organisation and so many files saved to the desktop (brilliant on a roaming profile) that you couldn’t see the desktop image.

I expect Windows to offer me my most commonly used applications in the Start menu too.

Which is terminal pain in the ass when you have something that’s used on say a monthly basis that goes AWOL from the regularly used list.

¹ Nurse Nice and all that – yep we have non-technical staff too – and she was face palming while describing it. My comment was “hey, it probably works fine at home” – maybe that was more sympathetic.

I do recall that we had laptops at work in the late 1990s and the only directories you could save stuff in were the ‘Program Files’ directory and the roaming profile. We were assured by a lying support person that our roaming profile was backed up so we saved all our work there. It took over 45 minutes to log off at the end of the day unless (if you were in a hurry) you removed the battery, at risk of losing the day’s work. (It would still be there is you started up with no remote telephone connection the next day.)

In fact they could just rebuild a blank profile. Fortunately the ‘backup’ was never put to the test!

Base problem: Profile too large.
Root cause: Lack of user organisation and so many files saved to the desktop (brilliant on a roaming profile) that you couldn’t see the desktop image.

Maybe I’m just an unreasonable user, but I see this as a technical problem that needs solving. Computers are supposed to make things easier for people! Yes, you would organise a room of papers into drawers/folders/etc. but if modern PC performance means we can find a needle in a haystack, then why bother?

I use Windows at work – have done for about 20 years. I don’t care what the Start menu looks like. I don’t care where stuff is installed on my drive (with one exception: my source code, because I need that to play nice with source control systems). I just let stuff be, and I can find it with search. Same with email: about the only positive thing Google have done is to demonstrate that email can be searched. You don’t need to spend your life organising messages into folders.

I think RISC OS would benefit with some of the same ideas: stop worrying about disc structures. Embrace package managers! I must agree with Andrew’s observations about $.Apps vs. Resources:$.Apps driving him crazy. It’s insane. Just try explaining it to someone – the whole *AddApp thing is a terrible bodge.

(rant over: for now)

Computers are supposed to make things easier for people

True, but fortunately for my finances it doesn’t work like that.
That said, these days the PC stuff isn’t normally my problem because others have to chase around on that while I get a flat spot on my rear checking switches and firewalls (mostly) from my desk.

The profile problems is something I came up with a solution for about 14 years ago but the higher food chain wouldn’t allow the time for the implementation testing.

I use Windows at work – have done for about 20 years

About two thirds of the time I’ve been patching things together regarding that “item” and it seems to get less logical in each incarnation.

About two thirds of the time I’ve been patching things together regarding that “item” (Wimdows!) and it seems to get less logical in each incarnation.

Agreed. Version 10 is shocking. It is so unfinished and untested.

A very interesting question. Rather than discoursing on reasons, pros, cons, etc., here is a shot of my main screen.

Midscreen there’s the boot disc which adds to ROOL’s HardDisc4 these directories:
Data organized by Topics and People
Develop for programming tools
Manuals for centralizing documentation
System for apps like FontDirPro, HForm and OS updates
Temp for Scrap, Transient and Logs

Apps contains most applications; they are stored within directories named by Category. Like in PackMan (but unlike in PlingStore) my Categories are discrete, they name the area of application, and they exclude unhelpful names like Utilities and Miscellaneous. 26-bit apps are categorized similarly within Apps.Apps26.

Where I prefer to relocate an app, I use ShortCut to leave a reference to it in its usual place, e.g. to keep !Scrap and !Fonts outside !Boot.

Along the top of the screen are instances of Toolbar for quick access to the most used apps, again by Category. Three are shown dropped down, but normally they are all rolled up.

AppDock has tiles down the left of the screen: those with graphic letters open app directories (e.g. N opens Network apps, and the lower ones open data directories (e.g. A opens Addresses). The topmost tile gives Boot Configure, the one labelled Apps opens DirMenu on the Apps directory to provide the hierarchy of menus that is shown here down to HouseOfCards, and mainly used for launching the less common apps.

AppDock provides also tiles that are shortcuts to controlling keys for the application that has the input focus. In this screenshot, the shortcuts are to keys provided by QFiler.

It’s worth noting that, while each Toolbar depends on the list in a static file, DirMenu’s menus are dynamic.

All the Filer displays are By Type, and most are Full info.

Wow! That looks so organised!

I still use “themed” dirs , like Text , Graphics, Network etc

Text documents lives in Text.Documents.subdirs
Music files lives in Music.musicfiles..
And the programs in the same way.

All is in $

I have used this layout since for ever.