Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> Usabilty Enhancements
 

Pages: 1
LLBLGen Pro Runtime Framework
Usabilty Enhancements
Page:1/1 

  Print all messages in this thread  
Poster Message
Stoop
User



Location:
Reno, Nevada
Joined on:
28-Feb-2004 12:01:28
Posted:
66 posts
# 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

  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37321 posts
# 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 Regular Smiley 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 Regular Smiley

Quote:

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 Regular Smiley (now it's cntrl-e to open the editor on the selected node)

Quote:

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.

Alt
hough it might sound great, you will regret it sooner or later. Regular Smiley 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 Regular Smiley.

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. Regular Smiley

Quote:
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 Regular Smiley. If you have more, keep them coming! Regular Smiley


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Stoop
User



Location:
Reno, Nevada
Joined on:
28-Feb-2004 12:01:28
Posted:
66 posts
# 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...


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37321 posts
# 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.

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

Quote:

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.

Quote:

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 Regular Smiley (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. Regular Smiley


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Stoop
User



Location:
Reno, Nevada
Joined on:
28-Feb-2004 12:01:28
Posted:
66 posts
# 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...
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37321 posts
# 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. Regular Smiley


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.