Dear Farty:
Looking good. Since you're only showing examples, rather than an actual layout, it's hard to critique, especially since there's nothing wrong with following SC's style.
Sounds: Maybe, as long as the buttons don't need frequent use, which would risk an annoyance factor.
Tabs: Which tab are you in? The bottom line beneath your current tab needs to vanish to indicate which tab is active (as tabs usually function).
About: What will be in this menu, specifically?
Install: Terminology is most effective when it's consistent. How about "Patch" instead? It is what Blizzard calls them, it's what the gaming world calls them. Installing is a word best reserved for full program installs, not incremental changes (ie, patches).
Help Box: These are all the rage in other programs, such as DatEdit and FireGraft. Why not follow such a great trend? It'd be an area at the bottom where helpful info can be displayed about any item the user clicks on or mouses-over. Much more effective than a disconnected help menu or somesuch.
Mod Library: An online database would be nifty, but I don't think it should be core. The foundation of the system would be most effective and simplest as a local user-controlled database. Online retrieval could be added in addition, but the feature should not be dependent upon the internet due to its many hurdles in implementation and maintenance.
Not to mention, a list of all mods and all their release versions could become unsightly in scale, rendering its usage unwieldy. That might be fun for completists, but some users may prefer simpler lists of their personal collection and favorite mods. On second thought, however, mods a user does not have, but are in the database, could be set to hide from view to keep the list manageable.
Nonetheless, given the level of work and dedication such an online endeavor would require, I don’t think it’s much bother to have users make their own archives. Personally, I’d prefer making my own, since I’m anal about how I organize things. This would only be a one-time setup, anyway, much better than what we currently have to do with reading the ReadMe.txt or forum post of a mod just to figure out what version of SC we need to patch to every time we want to play a different mod. If anything, SCD could ship with a default database.
I envision a tab after Install (Patch), which contains a list field set like a folder's Details view. The list can be sorted by its columns, just like a folder's Details view. At either the top or bottom would be several buttons: "Add", "Play", and "Link".
When you click Add, you are treated to a search menu, like the Open dialogue box of most programs (say, for instance, Word). If there is a way for the program to identify what version the mod requires, that'd be swell, but otherwise the user would be prompted to input the version of SC the mod requires as well as the optional ability to name the entry (otherwise it just uses the file's name).
When adding mods, you could add either a specific mod or a folder where many mods are kept (with the ability to look one folder layer deeper, should those mods be kept inside their own folder with their readme documents and such). When adding a folder, any necessary information, such as SC Version, that it cannot ascertain automatically will be required in a prompt when attempting to play the mod from the Library.
Once a mod is successfully entered into the local database, it will appear in the list field. It would have a tiny version of its icon followed by its custom library name, which the user can modify with a right-click -> Rename. They can also slowly double-click on the text to rename it at any time, too.
The column headings could be:
- Status (a red X if the mod is no longer found at the stored Path, which can be clicked on to update the mod's location)
- Name (custom, but otherwise pulls from the *.exe's file name)
- Mod Version (optional setting, to distinguish it when multiple entries have the same name but are different versions of the same mod)
- SC Version (SC or BW icon, too?)
- Update (blank unless set, contains a link to the mod's website)
- Author (blank unless set)
- Path (just shows the last folder and filename, but when moused-over it will show the full path in one of those hovering info boxes)
- Plays (how many times run from the mod library)
- Rating (user's choice, shared databases would probably make the best usage of this)
- Type (StarDraft, MPQDraft, MemGraft, or FireGraft mod? What version of each program if possible to distinguish)
- Date Created (Mod's creation date based on its file properties)
- Date Added (when you added it to the Library)
- Size (eh, why not?)
A column heading can be clicked on to sort by ascending or descending values, along with a hide/show option to streamline the details. Headings can also be dragged to change their horizontal order, as well as resized.
If users collect mods of different versions, they could create a folder to group all like mods into, with a + button expansion toggle, similar to DatEdit and FireGraft. Folders could be used for any other kind of grouping the user desires, allowing them to tailor their database to their needs and preferences.
The Play button would do the obvious: load whichever mod you currently have selected and preload its required patch. If a Folder is selected, it could run the first item in the folder, not do anything at all, or a column heading priority can be set on the folder (such as highest Mod Version).
The folder’s load priority would be user-selected when the folder is created, and modifiable. A folder would not have any of the normal information displayed like files under the various column headings, instead being blank except in the case of its Load Priority. An up/down arrow icon, like a dual state radio button, could be set in one column category and quickly changed with a click in another category, and a second click to change up/down (ascending/descending).
When sorting (clicking on the heading columns), Folders could either default to the top, or be sorted by whatever mod contained within them has priority.
The Link button would allow you to compile a shortcut-like batch file for whatever mod you have selected. Multi-selection could also be possible to make shortcut files for your entire library. All you would determine is the save location, as the filename would derive from the library’s Name category.
The “shortcut” batch would run the mod like the Play button, except without loading an active SCD window. Double-clicking on the shortcut file would seamlessly prepatch SC and load the mod it was built for all in the background.
The Library interface, with all its sorting options and folder organization, is ideal for managing large mod collections. The Links, on the other hand, are best for streamlining play for a few of your favorite mods that you play most often. You could put them on your desktop, double-click, and immediately begin gaming. Yet, when feeling nostalgic, you can go back to the Library.
Any mod can be removed from the database by selecting them in the list and hitting Delete or right-clicking and selecting the Delete option. A Yes/No prompt would pop up to ensure the user intended the action.
Sharing databases is tricky, and in a way would be kind of silly without the mods themselves, unless an ability to Download were present.
If a Load Database option was available, it could potentially read from a foreign database file and insert new entries while ignoring duplicate ones. The trick, then, is defining how the program will determine between new and duplicate records. It could rely on Name and Mod Version comparisons, but would it be case sensitive? How annoying would typos get if you find yourself clearing a dozen repeats because one thing or another was slightly off? Maybe a prompt showing what will be added first, with an easy unselect method to axe copies.
Plugin: New mods could be outfitted with a MPQDraft or FireGraft plugin that looks for SCD in the registry. If found, the mod inserts its information into the Library automatically, and then acts like a Link batch (prepatching SC to the needed version with SCD’s background installer).
For older mods, or mods made with tools not compatible with the Plugin for whatever reason, a second approach would be a special *.txt file. Or, more to the point, SCD looks for a unique syntax that the Add Mod option can read and extract settings from. If using a simplistic syntax with a header/footer tag, such code could be unobtrusively contained in the ReadMe.txt itself. In fact, the Add Mod option could be set to automatically scan any .txt files in the same directory as the mod for such syntax, so the end-user wouldn’t even have to know about it when setting up their Library.
With both the Plugin and text file syntax, certain fields can be of greater use to modmakers. In particular is the Update category. Now, it could merely link users to the author’s website, but a more advanced option could allow the creator to direct the link to a text file that contains the current mod version. The program would then compare and inform the user whether they are outdated or not.
Here’s how I envision new users setting up shop: The dedicated staff of SEN and other sites will add the syntax needed to the ReadMe files of their mods. New users are instructed to download SCD first, install it, and select a common folder where they will keep all their mods. As they download mods and extract them to that common folder, SCD will, on load, automatically update the database with those mods, and will pull all info needed from the ReadMe text files. The end-user now only has to select a mod from the Library to play. Done.
Another idea occurred to me: Links could act like a halfway between the Plugin and ReadMe. A Link for a mod made by someone else could be distributed along with the mod, if it contains all the database info as a redundancy. If a traded Link cannot find the mod, a prompt on execute will ask for the user to locate it.
This page has been viewed [img]http://farty1billion.dyndns.org/Clicky.php?img.gif[/img] times!
Now it shows "Current Version: [Starcraft/Brood War] 1.x[b-f/.x]"
