Hello,
longer paths to directories in metastock datafeed configuration window cannot be read.
Pls. make it possible to change window size or add a slider for the paths box.
Regards
Robert
make datafeed configuration window sizeable
make datafeed configuration window sizeable
- Attachments
-
- tssmc020.JPG
- (26.56 KiB) Downloaded 833 times
Beyond the dialog mentioned above, this is a general situation that simply should not happen.
The only dialogs that should ever be fixed size are those that where the information cannot possibly exceed the width or height of the dialog.
All other dialogs should be resizable, always!
Please make sure every programmer contributing to the product understands this as policy, and that every tester is aware that failure to follow this policy is a "test failure" requiring the feature to be returned to the developer for correction.
This should never happen again in any future work - and the process of development/testing needs to ensure that.
Finally, all existing instances of insufficient dialogs need to be revisited and corrected. This needs to be a scheduled work item for the next release.
I know it seems "preachy" to make such suggestions, but this sort of process failure creates completely avoidable repercussions (all negative), on product perception, user experience, customer support time, and software rework. The process is the point at which a fix eliminates all the negative repercussions. Fix the process itself, and the problems go away, permanently.
The only dialogs that should ever be fixed size are those that where the information cannot possibly exceed the width or height of the dialog.
All other dialogs should be resizable, always!
Please make sure every programmer contributing to the product understands this as policy, and that every tester is aware that failure to follow this policy is a "test failure" requiring the feature to be returned to the developer for correction.
This should never happen again in any future work - and the process of development/testing needs to ensure that.
Finally, all existing instances of insufficient dialogs need to be revisited and corrected. This needs to be a scheduled work item for the next release.
I know it seems "preachy" to make such suggestions, but this sort of process failure creates completely avoidable repercussions (all negative), on product perception, user experience, customer support time, and software rework. The process is the point at which a fix eliminates all the negative repercussions. Fix the process itself, and the problems go away, permanently.
Let me put it another way -
Do you have a development checklist?
Do you have a testing checklist?
If so, add the above and rock on ...
But if you do not have checklists for developers and testers, you need them, just the way a pilot needs a checklist for use when flying an airplane. It's not that the pilot is an idiot, or doesn't know his job, or lacks general skill. It's just that human beings are imperfect, and situations are unpredictable. Following a checklist before every takeoff and landing ensures that entire classes of avoidable errors are in fact avoided, every time that the checklist is followed.
If you don't actually have these checklists, you need them. In a 1 hour meeting you could probably write down 75% of what needs to be there. Then, as new issues arise (whether detected internally, or by users), you can simply add all mechanically avoidable errors to the checklists. Quality will soar.
If you are already doing this, just chuckle at my presumption. Otherwise, I strongly suggest you adopt this highly effective practice. Thanks!
Do you have a development checklist?
Do you have a testing checklist?
If so, add the above and rock on ...
But if you do not have checklists for developers and testers, you need them, just the way a pilot needs a checklist for use when flying an airplane. It's not that the pilot is an idiot, or doesn't know his job, or lacks general skill. It's just that human beings are imperfect, and situations are unpredictable. Following a checklist before every takeoff and landing ensures that entire classes of avoidable errors are in fact avoided, every time that the checklist is followed.
If you don't actually have these checklists, you need them. In a 1 hour meeting you could probably write down 75% of what needs to be there. Then, as new issues arise (whether detected internally, or by users), you can simply add all mechanically avoidable errors to the checklists. Quality will soar.
If you are already doing this, just chuckle at my presumption. Otherwise, I strongly suggest you adopt this highly effective practice. Thanks!
Hello,
I think also a windows like "Insert Symbols Into Portfolio" should be resizeable...
And why should there so much space between Lookup and the symbollist? And why is the symbollist with this fixed size?
Thanks
I think also a windows like "Insert Symbols Into Portfolio" should be resizeable...
And why should there so much space between Lookup and the symbollist? And why is the symbollist with this fixed size?
Thanks
- Attachments
-
- resize.PNG
- (18.85 KiB) Downloaded 824 times
- Marina Pashkova
- Posts: 2758
- Joined: 27 Jul 2007
Hi everybody,
Thank you very much for drawing our attention to the dialogue windows size issue. Your suggestions are very valuable and we appreciate your contribution. We have planned improvements in the GUI for the next quarter.
Re checklists: we do have those. Developing products as complex as MultiCharts would be simply impossible without an elaborate checklist system.
Thank you.
Regards.
Thank you very much for drawing our attention to the dialogue windows size issue. Your suggestions are very valuable and we appreciate your contribution. We have planned improvements in the GUI for the next quarter.
Re checklists: we do have those. Developing products as complex as MultiCharts would be simply impossible without an elaborate checklist system.
Thank you.
Regards.
Resizable dialogs desperately needed
I see the latest Beta has not addressed the pressing usability need for resizable dialogs.
The optimize, backtest, and format dialogs (and surely others) desperately need to be resizable.
If MC 3.0 is formally released without improvements in this area, it will be a tragedy.
One programmer can make simple changes that produce a major enhancement in the program's usability - for hundreds of users, everyday.
IMO, failure to do this is to be insensitive to the reality of customer experience in a MAJOR way.
Sorry to be so adamant about this, but I really do think the need for everyday usability is being underappreciated in the extreme wrt. resizable dialogs.
(but being able to type in symbols directly is GREAT!)
The optimize, backtest, and format dialogs (and surely others) desperately need to be resizable.
If MC 3.0 is formally released without improvements in this area, it will be a tragedy.
One programmer can make simple changes that produce a major enhancement in the program's usability - for hundreds of users, everyday.
IMO, failure to do this is to be insensitive to the reality of customer experience in a MAJOR way.
Sorry to be so adamant about this, but I really do think the need for everyday usability is being underappreciated in the extreme wrt. resizable dialogs.
(but being able to type in symbols directly is GREAT!)
- Attachments
-
- TinyDialog.png
- (14.27 KiB) Downloaded 824 times
Last edited by MC_Prog on 26 Feb 2008, edited 1 time in total.
- Andrew Kirillov
- Posts: 1589
- Joined: 28 Jul 2005
- Has thanked: 2 times
- Been thanked: 31 times
- Contact:
MC_Prog,
I agree that it is important feature, because a user suffers from it everyday. However we focused on major features and couldn't dedicate a few days to fix such small bug important issues.
We will include in our development plan small, but important GUI things.
I apologize it is not available yet.
I agree that it is important feature, because a user suffers from it everyday. However we focused on major features and couldn't dedicate a few days to fix such small bug important issues.
We will include in our development plan small, but important GUI things.
I apologize it is not available yet.
Andrew,
Thanks for your response, I appreciate it, and appreciate as well that everything can't all be done at once!
Let me just say that I think MC has a great feature set at this point, and making that feature set rock-solid-reliable and super-fast-and-easy to use would be good choices for what to concentrate fully on during the next few months. Also, documentation and code compilation issues need and deserve focussed attention.
Solve those things and you will have a great product for users to research and trade with and for developers to add on to. After that, you can take all the time you need for the next level of "deep, powerful" features because everyone will be happily using the current version and telling their friends how great it is!
Thanks for your response, I appreciate it, and appreciate as well that everything can't all be done at once!
That's good news (but I hope the plan isn't to do it in 2009 ).We will include in our development plan small, but important GUI things.
Let me just say that I think MC has a great feature set at this point, and making that feature set rock-solid-reliable and super-fast-and-easy to use would be good choices for what to concentrate fully on during the next few months. Also, documentation and code compilation issues need and deserve focussed attention.
Solve those things and you will have a great product for users to research and trade with and for developers to add on to. After that, you can take all the time you need for the next level of "deep, powerful" features because everyone will be happily using the current version and telling their friends how great it is!
- Andrew Kirillov
- Posts: 1589
- Joined: 28 Jul 2005
- Has thanked: 2 times
- Been thanked: 31 times
- Contact:
Definitely not 2009That's good news (but I hope the plan isn't to do it in 2009 ).
What things do you need to be optimized for speed? What things are not stable? I’m taking about MC 3.0Let me just say that I think MC has a great feature set at this point, and making that feature set rock-solid-reliable and super-fast-and-easy to use would
be good choices for what to concentrate fully on during the next few months.
We described all functions available in PowerLanguage. What things do you think we didn’t cover?Also, documentation and code compilation issues need and deserve focussed attention.
What compilation issues do you have? Please list
Thank you for the comments!
I'm referring to all the bugs reported in the Forum. The goal would be to start seeing alot of users saying "Wow, MC is rock-solid, good job!", and very few bug reports.What things are not stable? I’m taking about MC 3.0
For example, MC_Portfolio is not documented at all (yet).We described all functions available in PowerLanguage. What things do you think we didn’t cover? What compilation issues do you have?
Old business:
If the compiler encounters a reserved word that is not available yet in MC, it should stop and throw an error message.
As for speed, I mean use-of-use speed. As already discussed, the issue of resizable dialogs remains outstanding. They should all be fixed, and it should never happen again.
There are other particulars, but there is no lack of places to start!
What I'm saying in general is: Freeze the core features (for awhile), and make the reliability and usability top-notch (incl. data issues).
Others might disagree, but that's my opinion on what's needed most at this point.
- Andrew Kirillov
- Posts: 1589
- Joined: 28 Jul 2005
- Has thanked: 2 times
- Been thanked: 31 times
- Contact:
It is not specific answer and I can tell you that "Wow, MC is rock-solid, good job!" never happen, because we live in real word where datafeeds have problems, people misuse/misunderstand software functionality and other 3d party factors we can’t control. As you probably know many users are happy with stability of MultiCharts.I'm referring to all the bugs reported in the Forum. The goal would be to start seeing alot of users saying "Wow, MC is rock-solid, good job!", and very few bug reports.What things are not stable? I’m taking about MC 3.0
We fixed almost all reported bugs.
It will be done in the release version. We are completing it.For example, MC_Portfolio is not documented at all (yet).
I appreciate your comments. These are all realities.... because we live in real word where datafeeds have problems, people misuse/misunderstand software functionality and other 3d party factors we can’t control.
Well, OK, that's good. (Accepting your assertion as given.)We fixed almost all reported bugs.
As you are probably aware, there are many modern web-oriented bug report and tracking tools that are specifically designed to help users and developers work together in the reporting, tracking, and closing of bugs.
Using such tools comprehensively ensures that no bug report is ever lost, and that every bug is addressed, either solved or explicitly tabled for a stated reason.
Personally, I think it is a "best practice" to use such tools on a complex product like MC. Every person then can know both where their own reports stand and how well all reports in general are being addressed.
Setup effort for such tools, these days, is fairly minimal. So minimal, in fact, that not using them pretty clearly points to a policy decision that such information is not desired to be available to customers.
Every company has the right to decide such policies, certainly. There are many considerations. However, if customer-orientation is to be primary, such tools simply must be used. (My opinion, others may differ.).
Regarding MC_Portfolio docs:
That's great. Thanks!It will be done in the release version. We are completing it.