make datafeed configuration window sizeable

Questions about MultiCharts and user contributed studies.
User avatar
gautama2
Posts: 96
Joined: 10 Jul 2007
Has thanked: 1 time
Been thanked: 1 time

make datafeed configuration window sizeable

Postby gautama2 » 05 Nov 2007

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
Attachments
tssmc020.JPG
tssmc020.JPG (26.56 KiB) Viewed 727 times

User avatar
MC_Prog
Posts: 330
Joined: 28 Feb 2007
Has thanked: 64 times
Been thanked: 33 times

Postby MC_Prog » 08 Nov 2007

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.

User avatar
MC_Prog
Posts: 330
Joined: 28 Feb 2007
Has thanked: 64 times
Been thanked: 33 times

Postby MC_Prog » 08 Nov 2007

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!

dupl
Posts: 158
Joined: 04 Jul 2007

Postby dupl » 08 Nov 2007

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
Attachments
resize.PNG
resize.PNG (18.85 KiB) Viewed 718 times

User avatar
gautama2
Posts: 96
Joined: 10 Jul 2007
Has thanked: 1 time
Been thanked: 1 time

Postby gautama2 » 08 Nov 2007

lots of space can also be used here.
Attachments
tssmc021.JPG
Format signals window
tssmc021.JPG (24.73 KiB) Viewed 721 times

User avatar
Marina Pashkova
Posts: 2758
Joined: 27 Jul 2007

Postby Marina Pashkova » 08 Nov 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.

User avatar
MC_Prog
Posts: 330
Joined: 28 Feb 2007
Has thanked: 64 times
Been thanked: 33 times

Resizable dialogs desperately needed

Postby MC_Prog » 26 Feb 2008

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!)
Attachments
TinyDialog.png
TinyDialog.png (14.27 KiB) Viewed 718 times
Last edited by MC_Prog on 26 Feb 2008, edited 1 time in total.

iso
Posts: 204
Joined: 08 Feb 2006
Has thanked: 1 time
Been thanked: 1 time

Postby iso » 26 Feb 2008

I agree, this would be a great feature.

User avatar
Andrew Kirillov
Posts: 1589
Joined: 28 Jul 2005
Has thanked: 2 times
Been thanked: 31 times
Contact:

Postby Andrew Kirillov » 29 Feb 2008

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.

User avatar
MC_Prog
Posts: 330
Joined: 28 Feb 2007
Has thanked: 64 times
Been thanked: 33 times

Postby MC_Prog » 02 Mar 2008

Andrew,

Thanks for your response, I appreciate it, and appreciate as well that everything can't all be done at once!

We will include in our development plan small, but important GUI things.

That's good news (but I hope the plan isn't to do it in 2009 :wink: ).

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!

User avatar
Andrew Kirillov
Posts: 1589
Joined: 28 Jul 2005
Has thanked: 2 times
Been thanked: 31 times
Contact:

Postby Andrew Kirillov » 05 Mar 2008

That's good news (but I hope the plan isn't to do it in 2009 ).

Definitely not 2009 :)
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.

What things do you need to be optimized for speed? What things are not stable? I’m taking about MC 3.0

Also, documentation and code compilation issues need and deserve focussed attention.

We described all functions available in PowerLanguage. What things do you think we didn’t cover?
What compilation issues do you have? Please list

Thank you for the comments!

User avatar
MC_Prog
Posts: 330
Joined: 28 Feb 2007
Has thanked: 64 times
Been thanked: 33 times

Postby MC_Prog » 07 Mar 2008

What things are not stable? I’m taking about MC 3.0

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.

We described all functions available in PowerLanguage. What things do you think we didn’t cover? What compilation issues do you have?

For example, MC_Portfolio is not documented at all (yet).

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.

User avatar
Andrew Kirillov
Posts: 1589
Joined: 28 Jul 2005
Has thanked: 2 times
Been thanked: 31 times
Contact:

Postby Andrew Kirillov » 10 Mar 2008

What things are not stable? I’m taking about MC 3.0

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.


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.
We fixed almost all reported bugs.


For example, MC_Portfolio is not documented at all (yet).

It will be done in the release version. We are completing it.

User avatar
MC_Prog
Posts: 330
Joined: 28 Feb 2007
Has thanked: 64 times
Been thanked: 33 times

Postby MC_Prog » 14 Mar 2008

... because we live in real word where datafeeds have problems, people misuse/misunderstand software functionality and other 3d party factors we can’t control.

I appreciate your comments. These are all realities.

We fixed almost all reported bugs.

Well, OK, that's good. (Accepting your assertion as given.)

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:

It will be done in the release version. We are completing it.

That's great. Thanks! :)


Return to “MultiCharts”