PDA

View Full Version : Poll - UI Improvements needed



Garret Mott
6-Mar-2009, 11:08 PM
Hi All -

I'm starting a poll (actually 2 - but more on that in a minute) about what are the most needed User Interface improvements to VDF. This is not about improvements to the studio/coding, etc. There will be another poll along shortly about that.

Please choose 3 (& only 3) of the items you think are most important. Feel free to post other things I've missed. The intention here is to get all of us (developers & DAW) thinking about what's most important for VDF.

Thanks!

Peter Crook
7-Mar-2009, 09:25 AM
Hi All -

I'm starting a poll (actually 2 - but more on that in a minute) about what are the most needed User Interface improvements to VDF. This is not about improvements to the studio/coding, etc. There will be another poll along shortly about that.

Please choose 3 (& only 3) of the items you think are most important. Feel free to post other things I've missed. The intention here is to get all of us (developers & DAW) thinking about what's most important for VDF.

Thanks!

Garret, I think you know mine:

Null relationship support (I've implemented it but it relies on my having augmented undocumented and therefore liable-to-be-changed-without-my-noticing procedures);

and consequently a delete-nullifies rule (as well as delete cascades/delete restricted)

Delete rule to be specific for each child file;

Cascade updates (which means a similar rule as for deletes: update cascades/restricted/nullifies).

It would be nice to have some built-in support for sub-entities (which I implement as one-to-one relationships, although it may be that I have just not worked out the best way to deal with these yet). Usage - main entity name, which has sub-entities customer, supplier, employee, member. I don't want all the customer/supplier/... information in the name file, as not all names are customers etc, but some names might be both customers and suppliers and I don't want to duplicate their names and addresses).

Peter

PS Just realised - these aren't UI Improvements: sorry, should have wanted for your database improvements pol ;-)

Pak
9-Mar-2009, 04:14 AM
I want it so badly that I voted for New Data Grid...twice! I see a lot of other people have too...

Garret Mott
9-Mar-2009, 08:41 AM
I want it so badly that I voted for New Data Grid...twice! I see a lot of other people have too...

And of course the OP put it in there twice 'cause he didn't have any bias whatsoever! :D

chuckatkinson
9-Mar-2009, 11:15 AM
I voted for the new grid as something that is long overdue for improvement. But realized that WebApp is just as important. It needs to run on Apache and needs to have visual design tools in the Studio. If DAW would look at what IBM is doing with Telemon (Visual Ajax) that would be a good start.

These are not trivial projects for DAW to undertake. They spend so much time on improving the IDE that real change is put aside, and year after year we get the latest Studio changes with no underlying base changes.

Torkild Resheim had a VERY good start with VDF in Eclipse (albeit w/o visual modeling). The Eclipse platform (written by IBM and since Open Sourced) has hundreds of plugins available and products built on it, including the above Telemon. Imagine not having to write 10's of thousands of lines of VDF code for a changes in the Studio IDE and concentrate those resources improving VDF.

Hendrik van Niekerk
9-Mar-2009, 12:34 PM
I often have the need to have more than one line in a text box. (Without the need to have multi-single text boxes underneath each other.)

The way I add a block of text now is in an edit object and that works fine but so much more work.

So, with a multi-line text box one would enter text and "LF/CR" and when it displays anything after the "LF/CR" is placed on the next line.

Just a thought.

Maybe there is another way already, I would like to hear if there is.

Hendrik van Niekerk
9-Mar-2009, 12:36 PM
I'd also like to see an improved Tree-View class using native arrays, and the speed (as more and more items are added) to be improved.

Vincent Oorsprong
9-Mar-2009, 12:38 PM
Hendrik,

What would be the purpose of native arrays in a treeview? You only duplicate the need for memory...

Hendrik van Niekerk
9-Mar-2009, 12:40 PM
I also, I'm on a roll here, like to see an improved selection list class. One that I can populate from an array, Vincent already knows about this, as I asked him about one a few months ago. I had to write a SL using a grid class, populated from a SQL script into an array and then into the Grid, a way around it, but far too much work. It needs to be more generic.

Hendrik van Niekerk
9-Mar-2009, 12:42 PM
So Vincent you think the tree-view as it is now is optimal? I need the ability to have more than a single integer item number. I can not, for instance store rowID's as it only accepts integer as items.

Vincent Oorsprong
9-Mar-2009, 12:46 PM
Hendrik,

Ok, I get it but that is easy. Store the rowid in an array (or an array of structs) and store the element id in the userdata (itemdata) attribute. To automate this would be very difficult. What should we use? An array, an array of structs? And what type struct should it be?

Anders Ohrt
9-Mar-2009, 12:53 PM
Polls are nice, but I vote for setting up a UserVoice for VDF. That way, everyone could suggest changes and we all get to vote so what's most interesting for the community would show.

Hendrik van Niekerk
9-Mar-2009, 12:55 PM
Why not let the user define the structs, or array of structs. I'm not talking about hundreds of different variables or datatypes, but at least have the capability to store a rowID without having to add yet another array which needs to be kept in sync.

Garret Mott
9-Mar-2009, 01:22 PM
Polls are nice, but I vote for setting up a UserVoice for VDF. That way, everyone could suggest changes and we all get to vote so what's most interesting for the community would show.

I agree, but I used the tools available. :o

In case people are wondering why I chose to do these polls, I'll explain. Please understand that in general, I think DAW does a really good job at listening to us. Certainly way better than 99% of the companies I deal with. That being said.....

Last year @ Synergy, I mentioned that while the CJ menus are great, to me a better grid was/is far more important. I was told that the feedback DAW had gotten was that menus were #1.

That surprised me, because neither I nor anyone I talked to (both @ Synergy & back in the world) had ever been asked.

So - being the ever-bashful person I am, I decided to post these polls to let us all (developers & DAW) see what this group feels is important.

I hope they are taken in the spirit intended - which is to get input from the folks who are out writing/selling the apps - not to offend anyone in any way, shape, or form.

I hope it works out for all!

Hendrik van Niekerk
9-Mar-2009, 01:28 PM
The intended solution that Vincent gave me, (See his answer to my other post on this) only works for a limited number of characters, and is not the solution I was wanting. So it's back to the edit object for me. Until a true multi-lined text box is available then the edit box will have to be the way to display more than one line and "unlimited" characters.

Pak
9-Mar-2009, 03:40 PM
Last year @ Synergy, I mentioned that while the CJ menus are great, to me a better grid was/is far more important. I was told that the feedback DAW had gotten was that menus were #1.

That surprised me, because neither I nor anyone I talked to (both @ Synergy & back in the world) had ever been asked.

Garret, I think there are two different world views operating here.

1. Marketing the Products.

For this to work, the products must look snazzy and flash. <controversial>Eye candy will win out over functionality in many cases as a lot of the time, the purchasers of software are not the users of the software. The users get to supply a checklist of features that the software has to satisfy and the purchasers find the one that they like best, which in the absence of actual personal working need for the software, is the one that looks prettiest and smoothest.</controversial>

From this angle, it's CodeJock FTW.


2. Creating the Products.

From a developer's viewpoint, the eye candy is less important than functionality. We prefer to spend 5 hours coding a complex working dbGrid than 30 hours getting the control to do things the way we need it to and ending up with a hack that works around the issues in the control. (OK, that's slightly exaggerated, but the principle applies.) A working control makes us productive in a way that no amount of eye candy can, and if we're following a RAD route of production, a much faster time to market and fewer bugs.

From this angle, it's language features FTW.


I think it depends on what your job is. Personally, I sit on the side of the fence with a large sandpit with a "2" carved into the sand with a spade, but if I was in sales/marketing and had to sell the product, I might prefer the side of the fence with a neatly-trimmed lawn and garden gnomes arranged artistically in the form of the number "1" in the latest Microsoft Constantia font...

Garret Mott
9-Mar-2009, 04:11 PM
Garret, I think there are two different world views operating here.

I think it depends on what your job is. Personally, I sit on the side of the fence with a large sandpit with a "2" carved into the sand with a spade, but if I was in sales/marketing and had to sell the product, I might prefer the side of the fence with a neatly-trimmed lawn and garden gnomes arranged artistically in the form of the number "1" in the latest Microsoft Constantia font...

No doubt, but........................... The difference is functionality only? Methinks not....

2339

2340

Pak
9-Mar-2009, 06:26 PM
Can't say I'm not in favour of eye candy, but your examples also have extra functionality - they provide features that would be difficult/impossible to do in standard VDF. That's not quite the case with the menus, at least not with the normal use of them (I'm certain that it's possible to do some pretty tricky things with the menus).

Garret Mott
9-Mar-2009, 06:41 PM
Can't say I'm not in favour of eye candy, but your examples also have extra functionality - they provide features that would be difficult/impossible to do in standard VDF. That's not quite the case with the menus, at least not with the normal use of them (I'm certain that it's possible to do some pretty tricky things with the menus).

I'm sure VDF would be limited in comparison with VB.net. However - True dbGrid had more options in its VB3 version (circa 1995 - 4 versions back from .net) than the 14.1 VDF grid.

I guess what I'm saying is that while I don't mind the menus - in fact like 'em, let's get on to having a new grid!

Pak
9-Mar-2009, 07:02 PM
Agreed!