|Scribe: Stuff to delete and clean up for v2
|I've been inspired to clean out some cruft for Scribe v2 so that the UI and design is clean and easy to understand. The things that are going to be cut so far are:
- The "default" identity. Currently InScribe has a default identity that is carried over from i.Scribe so to speak. This tends to confuse people a lot. So I'm removing it and going with just the identities in the individual account's. This should map over to i.Scribe ok, in that it has one account and therefor 1 identity in that account.
- The C++ versions of the misc tools. The scripts should be fast and self documenting now. I will remove the C++ utilities in the Tools menu.
- The "Add Recipient" window. The search as you type drop down on the add recipient line is good enough for everyone now. I see no point duplicating functionality. If there is some missing functionality in the search as you type box I'll bring it up to speed.
- Some options will be moved into the advanced tab's tree control, which will go "live" soon. This will de-clutter the options dialog. I'm hoping to drop the tab count down so that they never need "scrolling" even with large fonts.
- The recipient entry edit box will be merged with the recipient list. Not sure on the details on this but it needs to be done.
- I'm thinking about removing email "Templates". I'm not sure they get used enough. Feel free to correct me if you think they should stay.
- The "security" options for folders and settings. I want to delete it and replace it with file system based permissions for folders/email and maybe an idle password if you havn't used the app for a while.
- Make the help html viewable in the built in HTML renderer, instead of relying on the host OS's web browser. Sometimes the host's HTML association is broken or pointing at something dumb (like MS Word!). So I can remove that pot hole by just rendering the help myself.
Which are all fairly tame I think. However there is one change that I'm considering thats a little risky. And that is the default location for settings and folders. Currently the default is in the same folder as the application install. Which works for single user Windows quite well. But it's been several years since Scribe has run on Linux and Mac OS X and well things just don't work that way on unix based operating systems. Their main concept is that the app sits in a central location and saves all it's user specific data somewhere in the user's home directory. A definate separation of application and data, and in Linux enforced with permissions so that users can't modify the application. Modern Windows applications follow the same model as well, the app sits in the Program Files hierarchy and the data is saved in the user's Application Data folder.
By default I think Scribe should move to this model. However Scribe has prided itself in being able to by portable so I'm considering making the install ask the user for a "desktop" install or a "portable" install and locate the settings and folders appropriately. That way people get the best of both worlds. There are some edge cases that will need smoothing over but I think it'll work in theory.
Backup/Copy: the user can no longer assume that operating on the app's folder will backup, copy or move their settings and email. So I will probably make some sort of menu for doing that manually. Maybe in the form of converting between desktop and portable storage post install. I'll probably get a fair bit of feedback about that in the next few v2 builds.
What else needs to be cut from v2?
always good to see you inspired.
Aren't you adding "cruft" as you call it by providing the settings location option.
Portability is (in my opinion) one of the main features, and ease of transporting, backupping and updating will suffer in the proposed system.
To save 3mb storage per user, in those cases where multiple users share a single "install"
I can see the need for seperating userdata and program data where programs are huge (bloated) things you dont want duplicates of. (office)
I can see the need when there is a forced use of (multiple) account structures.(windows)
I can see the need when there is big set of an administrator set of settings, but inscibe settings are mostly(if not all) user specific.
I say it's not worth the hassle, keep it simple, intuitive and clean.
Where is inscibe? where you put it.
Where are settings? same place as inscibe.
somebody else wants to use inscibe? here is 3mb of files, have a ball.
My 2 cents to get the discussion started.
|Yikes - please don't remove the template feature. I use this feature quite frequently and consider it to be one of the main selling features of the program.
I agree with Exo regarding the settings location.
The other changes sound reasonable. I didn't even realize that there was an 'Add Recipients' dialog, so I will definitely not miss it. It was good to hear about the improvements in scripting.
Any thoughts on when v2 will lose its alpha status and become beta or a full-fledged release?
I would also suggest to leave the template feature in Scribe program. Although I do not use it for the moment, I can imagine its application for some purposes.
I can understand the model of separate settings and program. I agree with the option of portability during the installation of Scribe. In the case of the portable version, I would suggest to save the settings in a separate subfolder (called e.g. Settings, similarly as subfolder Scripts is created) of Scribe program; otherwise it can be saved in the user specific directory for the desktop installation.
In a current version of Scribe, the last added recipient in the recipient edit entry box is put on the top of the recipient list. I would prefer to add the last added recipient at the end of the recipient list (while automatic scrolling down when there are more recipients in order to see the last added one), which may be possible in your newly suggested schema of adding of recipient.
The feature I still miss is the selection of printing just a selected page from a longer email. The dialog is there but it is not working - e.g. when I select to print just a page no. 1, it prints the whole message anyway. And printing all the time to pdf and then from this just a selected page is just annoying...
(Will be HTML encoded to evade harvesting)