Creativity & ActiveX controls, futuristic UI
-
T. Stih wrote: I find most of ActiveX controls technical and done by people who don't really have visions about how software of future should look like. ActiveX? Just say: no! I hope that ActiveX will simply disappear in the near future...
I'm talking about controls in general. Bulding blocks are a good idea. The technology really doesn't matter when there is no creativity present. Another interface - bubbles. Terms, represented with connected bubbles, affected by gravity forces (importance), being able to affect each other if dragged and moved forcefully and having resistance based on their business importance. Tomaz
-
Why are programmers so tasteless and visionless. I find most of ActiveX controls technical and done by people who don't really have visions about how software of future should look like. Here are some of fresh ideas: 1. Operations will be performed via diagramming instead of classical controls, because of the benefits of visual representation. Imagine classical way of adding an employee to a department today... If you're very lucky you end up dragging 'n' dropping the user from a table to the tree control, but this is rare, most of the time you simply open a look-up window in the department window and select the user which is then added to the department. In future you will have a small shape in a diagram representing a user (perhaps of rectangular shape, with incorporated photo and basic info on it) and a shape representing department, you'll simply connect them and create sort of hybrid between mind map and model... Knowledge level will provide meaningful choices between objects and make sure that you can't create impossible relations. You can do a lot of classical database operations by simply connecting objects and explaining the nature of formed relationships. For example, connect shapes user and department and create relationship is-manager-of. Connect user to user and establish accountability (boss, worker) relationship. Once I was developing application to manage car part. I had three windows each representing status of a truck. When a truck left the garage the user simply drag & dropped truck to window "on the way", same with "in repair", etc... 2. Simpler, realer! At the moment I am desperately seeking for account (konto) control. You know, the well known T, so that I wouldn't need to display transactions, summaries and other data in a grid but would simply show the accountant traditional view. Strangely enough - it's not there! All I can find are 100.000.000 fancy blinking, animated technie widgets. But no simple T with a header at the top, sum at the bottom, date from at right top and date to at right bottom, one column and N rows at each side of the T and scrollbar if there are too many entries. The closer thing to it is a grid and emulation. But there is no style... Oh, well. Looking forward to hear some of your ideas (?) Regards, Tomaz
T. Stih wrote: Looking forward to hear some of your ideas (?) While I agree in principal (to having a more visual way of adding records etc.) the sheer amount of extra work and extra knowledge required is prohibitive. There are systems where you drag the employee to a, for instance, bank account icon and it links them. But the amount of extra work to make that kind of functionality is just not currently worth it IMHO. Also think of all those millions of people used to doing it by typing and clicking and more typing. They would kick and scream if they had to do it differently, even if it was a better way (people hate change.) Also there are systems out there which organise knowledge items and info items into visual depictions. But they become very cluttered, very fast and people get even more "information overload." It will take many years, new dev tools, new ways of thinking etc. before what you say happens. regards, Paul Watson Bluegrass Cape Town, South Africa "The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge Sonork ID: 100.9903 Stormfront
-
Why are programmers so tasteless and visionless. I find most of ActiveX controls technical and done by people who don't really have visions about how software of future should look like. Here are some of fresh ideas: 1. Operations will be performed via diagramming instead of classical controls, because of the benefits of visual representation. Imagine classical way of adding an employee to a department today... If you're very lucky you end up dragging 'n' dropping the user from a table to the tree control, but this is rare, most of the time you simply open a look-up window in the department window and select the user which is then added to the department. In future you will have a small shape in a diagram representing a user (perhaps of rectangular shape, with incorporated photo and basic info on it) and a shape representing department, you'll simply connect them and create sort of hybrid between mind map and model... Knowledge level will provide meaningful choices between objects and make sure that you can't create impossible relations. You can do a lot of classical database operations by simply connecting objects and explaining the nature of formed relationships. For example, connect shapes user and department and create relationship is-manager-of. Connect user to user and establish accountability (boss, worker) relationship. Once I was developing application to manage car part. I had three windows each representing status of a truck. When a truck left the garage the user simply drag & dropped truck to window "on the way", same with "in repair", etc... 2. Simpler, realer! At the moment I am desperately seeking for account (konto) control. You know, the well known T, so that I wouldn't need to display transactions, summaries and other data in a grid but would simply show the accountant traditional view. Strangely enough - it's not there! All I can find are 100.000.000 fancy blinking, animated technie widgets. But no simple T with a header at the top, sum at the bottom, date from at right top and date to at right bottom, one column and N rows at each side of the T and scrollbar if there are too many entries. The closer thing to it is a grid and emulation. But there is no style... Oh, well. Looking forward to hear some of your ideas (?) Regards, Tomaz
These sound like great ideas that others would use - great programming & money making opt for you! Go for it! Oh, and by the way, things like these exist without ActiveX, as part of larger programs.
Visual Studio Favorites - www.nopcode.com/visualfav
-
Why are programmers so tasteless and visionless. I find most of ActiveX controls technical and done by people who don't really have visions about how software of future should look like. Here are some of fresh ideas: 1. Operations will be performed via diagramming instead of classical controls, because of the benefits of visual representation. Imagine classical way of adding an employee to a department today... If you're very lucky you end up dragging 'n' dropping the user from a table to the tree control, but this is rare, most of the time you simply open a look-up window in the department window and select the user which is then added to the department. In future you will have a small shape in a diagram representing a user (perhaps of rectangular shape, with incorporated photo and basic info on it) and a shape representing department, you'll simply connect them and create sort of hybrid between mind map and model... Knowledge level will provide meaningful choices between objects and make sure that you can't create impossible relations. You can do a lot of classical database operations by simply connecting objects and explaining the nature of formed relationships. For example, connect shapes user and department and create relationship is-manager-of. Connect user to user and establish accountability (boss, worker) relationship. Once I was developing application to manage car part. I had three windows each representing status of a truck. When a truck left the garage the user simply drag & dropped truck to window "on the way", same with "in repair", etc... 2. Simpler, realer! At the moment I am desperately seeking for account (konto) control. You know, the well known T, so that I wouldn't need to display transactions, summaries and other data in a grid but would simply show the accountant traditional view. Strangely enough - it's not there! All I can find are 100.000.000 fancy blinking, animated technie widgets. But no simple T with a header at the top, sum at the bottom, date from at right top and date to at right bottom, one column and N rows at each side of the T and scrollbar if there are too many entries. The closer thing to it is a grid and emulation. But there is no style... Oh, well. Looking forward to hear some of your ideas (?) Regards, Tomaz
T. Stih wrote: Why are programmers so tasteless and visionless. Golden rule of software development - don't let programmers design UI. They might be hot coders but very rarely do they understand users needs. Whilst your ideas might sound good, they aren't very practical - most users can bearly move the mouse never mind drag and drop something between calls. I'm no UI expert, but I was always taught to keep it simple. From my point of view it would be easier to have three radio buttons (push button style) for the truck status - "Truck in repair" , "Truck enroute", "Truck at destination". The user would then simply click the status. I like your idea of showing an accountant a traditional view of their ledger, it would make an interesting owner drawn control. It shouldn't be that hard to achieve. When I used to dabble in accounts software I always wanted to do something like that but schedule pressure never allowed for it. Michael :-)
-
T. Stih wrote: Why are programmers so tasteless and visionless. Golden rule of software development - don't let programmers design UI. They might be hot coders but very rarely do they understand users needs. Whilst your ideas might sound good, they aren't very practical - most users can bearly move the mouse never mind drag and drop something between calls. I'm no UI expert, but I was always taught to keep it simple. From my point of view it would be easier to have three radio buttons (push button style) for the truck status - "Truck in repair" , "Truck enroute", "Truck at destination". The user would then simply click the status. I like your idea of showing an accountant a traditional view of their ledger, it would make an interesting owner drawn control. It shouldn't be that hard to achieve. When I used to dabble in accounts software I always wanted to do something like that but schedule pressure never allowed for it. Michael :-)
Michael P Butler wrote: Golden rule of software development - don't let programmers design UI. They might be hot coders but very rarely do they understand users needs. I design and code *ALL* of our user interfaces. I've spent a lot of time reading UI related Documations including the book "About Face". I agree that the *majority* of programmers are clueless when it comes to UI. My golden rule is to lk at what the competion are doing. Normski. - Professional Windows Programmer
-
T. Stih wrote: Why are programmers so tasteless and visionless. Golden rule of software development - don't let programmers design UI. They might be hot coders but very rarely do they understand users needs. Whilst your ideas might sound good, they aren't very practical - most users can bearly move the mouse never mind drag and drop something between calls. I'm no UI expert, but I was always taught to keep it simple. From my point of view it would be easier to have three radio buttons (push button style) for the truck status - "Truck in repair" , "Truck enroute", "Truck at destination". The user would then simply click the status. I like your idea of showing an accountant a traditional view of their ledger, it would make an interesting owner drawn control. It shouldn't be that hard to achieve. When I used to dabble in accounts software I always wanted to do something like that but schedule pressure never allowed for it. Michael :-)
Michael P Butler wrote: Golden rule of software development - don't let programmers design UI. They might be hot coders but very rarely do they understand users needs. That is a contradiction. Good coders will also create a good GUI, because the good coders always research the subject they work on before they make their moves. Be it a GUI, be it whatever.
-
Michael P Butler wrote: Golden rule of software development - don't let programmers design UI. They might be hot coders but very rarely do they understand users needs. That is a contradiction. Good coders will also create a good GUI, because the good coders always research the subject they work on before they make their moves. Be it a GUI, be it whatever.
George wrote: That is a contradiction. Good coders will also create a good GUI, because the good coders always research the subject they work on before they make their moves. Be it a GUI, be it whatever. That may not be necessarity true. I can understand and research GUI needs, but when it comes down to it. A coder will always have an extra bit of knowledge that makes any UI a bit easier to use for him/her than for the intended user. In a large project, having a UI design person working with the users is better than keeping the good coders occupied with that. I'm not saying it never happens, but it usually doesn't. From an internal company e-mail November, 2001 -- "Would the person who stole the ethics training manual from the class last Friday please return it."
-
Michael P Butler wrote: Golden rule of software development - don't let programmers design UI. They might be hot coders but very rarely do they understand users needs. I design and code *ALL* of our user interfaces. I've spent a lot of time reading UI related Documations including the book "About Face". I agree that the *majority* of programmers are clueless when it comes to UI. My golden rule is to lk at what the competion are doing. Normski. - Professional Windows Programmer
Norm Almond wrote: My golden rule is to lk at what the competion are doing. But who says the competition are doing it "right"? Joel Lucsy (jjlucsy@ameritech.net)
-
George wrote: That is a contradiction. Good coders will also create a good GUI, because the good coders always research the subject they work on before they make their moves. Be it a GUI, be it whatever. That may not be necessarity true. I can understand and research GUI needs, but when it comes down to it. A coder will always have an extra bit of knowledge that makes any UI a bit easier to use for him/her than for the intended user. In a large project, having a UI design person working with the users is better than keeping the good coders occupied with that. I'm not saying it never happens, but it usually doesn't. From an internal company e-mail November, 2001 -- "Would the person who stole the ethics training manual from the class last Friday please return it."
Steven Mitcham wrote: A coder will always have an extra bit of knowledge that makes any UI a bit easier to use for him/her than for the intended user. And he should know that and take it into account. Otherwise he is just not a good coder after all. Steven Mitcham wrote: In a large project, having a UI design person working with the users is better than keeping the good coders occupied with that. Yeah, right. That is the best receipt for "stupid" GUI. No the person nor the users know what they want leave alone how the GUI should look and work like. They will have a lot of "brilliant" ideas that are not only hard to code but will also turn completely useless if implemented.
-
Norm Almond wrote: My golden rule is to lk at what the competion are doing. But who says the competition are doing it "right"? Joel Lucsy (jjlucsy@ameritech.net)
Joel Lucsy wrote: But who says the competition are doing it "right"? Chances are they aren't...so at least you can have a good laugh at them in the process... ;P Andy Metcalfe - Sonardyne International Ltd
Trouble with resource IDs? Try the Resource ID Organiser Add-In for Visual C++
"I would be careful in separating your wierdness, a good quirky weirdness, from the disturbed wierdness of people who take pleasure from PVC sheep with fruit repositories." - Paul Watson -
T. Stih wrote: I find most of ActiveX controls technical and done by people who don't really have visions about how software of future should look like. ActiveX? Just say: no! I hope that ActiveX will simply disappear in the near future...
George wrote: ActiveX? Just say: no! I hope that ActiveX will simply disappear in the near future... Just out of curiosity, why? I have never used it much myself, so I don't really care, but I can see where it might have value in the right situation. What technology do you use instead? "Thank you, thank you very much" Elvis.
-
George wrote: ActiveX? Just say: no! I hope that ActiveX will simply disappear in the near future... Just out of curiosity, why? I have never used it much myself, so I don't really care, but I can see where it might have value in the right situation. What technology do you use instead? "Thank you, thank you very much" Elvis.
It was a wonderful technology when limited to Windows desktop applications. However as Microsoft started to push it onto the web too, all it's security flaws were highlighted. This has caused ActiveX to become a dirty word to many. Of course ActiveX is just another name for COM, without which .NET would still be a pipedream. Michael :-)
-
It was a wonderful technology when limited to Windows desktop applications. However as Microsoft started to push it onto the web too, all it's security flaws were highlighted. This has caused ActiveX to become a dirty word to many. Of course ActiveX is just another name for COM, without which .NET would still be a pipedream. Michael :-)
I certainly agree with the security aspect of it. I just was not sure if there were other issues of which I was not aware. "Thank you, thank you very much" Elvis.
-
T. Stih wrote: Why are programmers so tasteless and visionless. Golden rule of software development - don't let programmers design UI. They might be hot coders but very rarely do they understand users needs. Whilst your ideas might sound good, they aren't very practical - most users can bearly move the mouse never mind drag and drop something between calls. I'm no UI expert, but I was always taught to keep it simple. From my point of view it would be easier to have three radio buttons (push button style) for the truck status - "Truck in repair" , "Truck enroute", "Truck at destination". The user would then simply click the status. I like your idea of showing an accountant a traditional view of their ledger, it would make an interesting owner drawn control. It shouldn't be that hard to achieve. When I used to dabble in accounts software I always wanted to do something like that but schedule pressure never allowed for it. Michael :-)
Michael, must say that windows with trucks and drag'n'drop feature were well accepted by the user. The problem space was small ( cca. 40 trucks, largest tobacco producer in Slovenia ;-), but small company in all other aspects ) and thus manageable. The app was simple productivity tool for one user (there were two employees working in car park before the app, but one was transferred to another work place after the introduction of app). I think it is a nice concept of tracing where your vehicles are at any given moment and having an approximate overview about the situation. Though the real value of app was in calculations it did on the cargo, gasoline, amortization, etc... Regards, Tomaz
-
T. Stih wrote: Looking forward to hear some of your ideas (?) While I agree in principal (to having a more visual way of adding records etc.) the sheer amount of extra work and extra knowledge required is prohibitive. There are systems where you drag the employee to a, for instance, bank account icon and it links them. But the amount of extra work to make that kind of functionality is just not currently worth it IMHO. Also think of all those millions of people used to doing it by typing and clicking and more typing. They would kick and scream if they had to do it differently, even if it was a better way (people hate change.) Also there are systems out there which organise knowledge items and info items into visual depictions. But they become very cluttered, very fast and people get even more "information overload." It will take many years, new dev tools, new ways of thinking etc. before what you say happens. regards, Paul Watson Bluegrass Cape Town, South Africa "The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge Sonork ID: 100.9903 Stormfront
Paul, I think we can agree that it all comes down to the size of the problem space and the real user's needs. One of the last apps I developed was high yield investment evaluation and monitoring system. Analysts in this system deal with max. 30 projects (that is a lot of investments to re-evaluate on regular basis for analyst). Then again, recently I did COTS CRM evaluation for the same company, having 8.000 contacts. It would make user interface a living nightmare to complicate with visualisation. Though I think it would come in handy when displaying customer's factsheet (what do I know about the customer?). The master - detail reports are simply too clumsy and non elegant. I suppose at the end it comes down to engineering, that is cost/benefit analysis, which good engineers are capable of making. Unfortunately, since there is a lack of commercial control libraries that would address a bit more abstract business problems it might take some time for new approaches to take off. But I am positive that diagramming has a future in communication with business apps. It's just natural way of doing some things... Regards, Tomaz
-
Paul, I think we can agree that it all comes down to the size of the problem space and the real user's needs. One of the last apps I developed was high yield investment evaluation and monitoring system. Analysts in this system deal with max. 30 projects (that is a lot of investments to re-evaluate on regular basis for analyst). Then again, recently I did COTS CRM evaluation for the same company, having 8.000 contacts. It would make user interface a living nightmare to complicate with visualisation. Though I think it would come in handy when displaying customer's factsheet (what do I know about the customer?). The master - detail reports are simply too clumsy and non elegant. I suppose at the end it comes down to engineering, that is cost/benefit analysis, which good engineers are capable of making. Unfortunately, since there is a lack of commercial control libraries that would address a bit more abstract business problems it might take some time for new approaches to take off. But I am positive that diagramming has a future in communication with business apps. It's just natural way of doing some things... Regards, Tomaz
T. Stih wrote: But I am positive that diagramming has a future in communication with business apps. It's just natural way of doing some things... I totally agree. Point in fact: I use Microsoft Visio virtually every day to design new systems. It is a wonderful tool to create visual, diagramatic representations of future systems. Before we wrote endless paragraphs about it, and those did not work. Now with a diagram what we said in 3 pages of text can be done in 1 simple diagram. It is wonderful. Also changing a diagram is far easier than changing a paragraph of text. So we have the "component", Visio. It has a full API and can be integrated with virtually anything. So I take back my "we need to develop the tools" remark :) The great thing about Visio also is that each item in a diagram can be linked to database and contain data themselves. You can connect up items and then infer from that the database relationship. So we may be closer than we think, but we still have to convince the general user that it is a viable, and better, way of doing things. We know, but they don't :) regards, Paul Watson Bluegrass Cape Town, South Africa "The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge Sonork ID: 100.9903 Stormfront