Usabilty Enhancements

Posts   
 
    
Stoop
User
Posts: 66
Joined: 28-Feb-2004
# Posted on: 28-Feb-2004 20:53:34   

Since a new version is set to be released soon, I thought I might make a couple of suggestions that, IMHP, would make the program a bit more user friendly.

The first suggestion I have is when you save a project. Right now, when you save a project, you get a dialog box saying "The file myfile.lpg already exists choose Yes.." My suggestion: get rid of this and also the "Project saved successfully" dialog that comes after it. It's rather, well... (don't get me wrong) annoying. If you take a look at other programs such as any Office program, notepad, VS.NET there is no dialog when you save asking you if you want to overwrite existing file. It's assumed. Also you don't get a "project saved OK" dialog. As a user, you assume it's been saved correctly unless notified otherwise. The above mentioned "The file myfile.lpg already.." dialog is perfect when you do a "Save as", but I don't think it should appear in a regular "Save"..

Another thing that would make the program a bit easier to use is double click methods on the Project explorer. For example, it would be nice to bring up the edit / properties tab by simply double clicking on the entity in question.

Last I think the automatic creation of a backup .lpg file when refreshing your catalog should be done away with. It should be an option in preferences or a yes/no dialog. Also, it would be nice if it simply connected to the db and retrieved the schemas. If a connection error appears then the "Catalog refresh. Connect to database' form shows allowing user to modify settings.

Just my suggestions, that's all. They are by no means complaints..

Steve

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 29-Feb-2004 12:39:10   

Stoop wrote:

The first suggestion I have is when you save a project. Right now, when you save a project, you get a dialog box saying "The file myfile.lpg already exists choose Yes.." My suggestion: get rid of this and also the "Project saved successfully" dialog that comes after it. It's rather, well... (don't get me wrong) annoying. If you take a look at other programs such as any Office program, notepad, VS.NET there is no dialog when you save asking you if you want to overwrite existing file. It's assumed. Also you don't get a "project saved OK" dialog. As a user, you assume it's been saved correctly unless notified otherwise. The above mentioned "The file myfile.lpg already.." dialog is perfect when you do a "Save as", but I don't think it should appear in a regular "Save"..

Good point, it illustrates people have different thoughts about topics simple_smile I built this in to alert the developer in every step s/he takes what that step does. I even considered a function which backs up the project file each time the project gets saved. It's important that the project files do not get corrupted or deleted or overwritten with data you don't want.

I'll add a feature which switches off this paranoia mode simple_smile

Another thing that would make the program a bit easier to use is double click methods on the Project explorer. For example, it would be nice to bring up the edit / properties tab by simply double clicking on the entity in question.

True, however double clicking a node is also used to open a node in trees. So that's not going to work, as some people don't click the [+] but double-click a node. I can add a cntrl-click feature to open the editor simple_smile (now it's cntrl-e to open the editor on the selected node)

Last I think the automatic creation of a backup .lpg file when refreshing your catalog should be done away with. It should be an option in preferences or a yes/no dialog. Also, it would be nice if it simply connected to the db and retrieved the schemas. If a connection error appears then the "Catalog refresh. Connect to database' form shows allowing user to modify settings.

Although it might sound great, you will regret it sooner or later. simple_smile The backup is made to be able to revert any refreshing of a catalog, as these refresh-actions can change your project dramatically (it now removes entities for example if the table is not found, this will change to a form where you can fix the mapping) and you probably don't want that. When you switch it off, you can run into trouble sooner or later by refreshing the project with a schema that ruins your project and you can't revert it back. That's why I build in the backup-copy creation. To protect ourselves against (rightfully) frustrated users and to protect our users against unforseen issues, this will not become an 'option' it will stay a mandatory thing simple_smile .

Refreshing the catalog is not something that is encouraged to do often: you should think through your database design first, then refresh the catalog in the project. However, it can be helpful to just use the parameters set the last time to refresh the catalog. It is already added (to the exe in the beta) that the last settings used to connect to the database can be set permanent and will be used next time you want to connect to the database. Security information like passwords are not stored however, so if you use databaseserver security you will always have to type in the password, otherwise it will become insecure to use LLBLGen Pro in some situations. Also, I think it is best that you overlook the settings you are about to use to connect to the catalog when refreshing it: you might have connected to a temporary testversion last time you refreshed the project, and when things go automatically, this is discovered perhaps in a later stadium. To avoid this, it's key that the user always confirms the connection parameters which are used to connect to the catalog/database. Perhaps a little paranoia at first, however it can never go wrong, and IF it goes wrong it is your own fault because you clearly confirmed the connection parameters. simple_smile

Just my suggestions, that's all. They are by no means complaints..

They're good points, I'm happy to explain the way the stuff is now and I'm happy to build in options like an easier way to open the editor tabs or a switch to ease the paranoia in the save-sequence simple_smile . If you have more, keep them coming! simple_smile

Frans Bouma | Lead developer LLBLGen Pro
Stoop
User
Posts: 66
Joined: 28-Feb-2004
# Posted on: 29-Feb-2004 13:55:29   

Thank you for your explanation of things..

I still think that the backup of the project, though, should be an option (default would be checked) in 'Preferences' that the user can uncheck if he/she so desires. Us users then will take the responsiblilty of any lost info since we were the ones that unchecked the box.

Also, maybe it would be nice to have the program backup to only ONE file, which is overwritten everytime a backup is created. I don't know about other users, but I don't plan on refreshing my database all that often, so I really don't need a new bku file everytime the I refresh the catalog. If I need to roll back it would be to the version just prior. Also, maybe a preference that would allow the user to give the backup a more meaningful name. The autoname (though I did figure it out) is a bit cryptic...

One last thing - what about a tool bar? Most programs have at least a basic tool bar with the most used functions new,open, save et...

Just my 2 cents worth...

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 01-Mar-2004 09:40:56   

Stoop wrote:

I still think that the backup of the project, though, should be an option (default would be checked) in 'Preferences' that the user can uncheck if he/she so desires. Us users then will take the responsiblilty of any lost info since we were the ones that unchecked the box.

simple_smile Well, you can take the responsibility, and others might too, but there are always people who think they can, but don't.

Also, maybe it would be nice to have the program backup to only ONE file, which is overwritten everytime a backup is created. I don't know about other users, but I don't plan on refreshing my database all that often, so I really don't need a new bku file everytime the I refresh the catalog. If I need to roll back it would be to the version just prior. Also, maybe a preference that would allow the user to give the backup a more meaningful name. The autoname (though I did figure it out) is a bit cryptic...

One backup file might be a good idea indeed. As long as there is a backup. So I think the option should be: 1 backup file which is always silently overwritten, or a new backup file each time you refresh.

One last thing - what about a tool bar? Most programs have at least a basic tool bar with the most used functions new,open, save et...

I did build in a toolbar in a certain point in development, but it turned out to be a very small button bar, and buttons which should start complex actions started to get very cryptic icons simple_smile (so you had to hover over teh button, to read the tooltip what it was). So I dropped the idea and opted for keyboard shortcuts instead. But I'll add it to the todo list, we could give it another go. simple_smile

Frans Bouma | Lead developer LLBLGen Pro
Stoop
User
Posts: 66
Joined: 28-Feb-2004
# Posted on: 05-Mar-2004 13:47:42   

Another useful improvement would be a way to "lock" the generator so as to prevent accidental overwritng of the code files. This could be a project level option that would disable the "generate" menu. Maybe even password protected..

I think this would protect the user from accidently generating changes unknown to him, for example in a multi user setting where a project leader doesn't want others to generate code files without his/her knowlege..

Again, just my 2 cents worth...

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 05-Mar-2004 14:19:03   

Stoop wrote:

Another useful improvement would be a way to "lock" the generator so as to prevent accidental overwritng of the code files. This could be a project level option that would disable the "generate" menu. Maybe even password protected..

I think this would protect the user from accidently generating changes unknown to him, for example in a multi user setting where a project leader doesn't want others to generate code files without his/her knowlege..

The project leader can do this already, by defining a new generator config (by copying an existing for example) and changing failWhenExistent to true. This way, the generator will never overwrite the file.

The GUI enhancements planned will make it possible to edit the config settings (and template set settings) as specified in the current selected config/template definition files in the gui, and eventually save them.

Personally I don't believe in password protected menu options. If a person isn't allowed to generate code, he shouldn't be able to run LLBLGen Pro, which means that it has an organisational solution. simple_smile

Frans Bouma | Lead developer LLBLGen Pro