Mario Blatarić
06.04.2012
Show all comments
-
really? cookie'd? holy crap, SC2.0 gets worse and worse.
-
I wouldn't agree and this kind of comments are not very productive. CM 2.0 is brand new product built from ground up (not an update) in extremly dynamic environment under high pressure. Every new product needs time to mature and we can help greatly with productive comments and bug reports.
Since every customer here is developer himself, I was quite suprised by amount of "hate mail" regarding SC 2.0. -
In actual fact Mario, this kind of comment expresses much of the frustration i, and others, feel. MY business relies on me using SC effectively. MOST of the abilities of SC has been removed, without warning or validation. And to add to this, if felt good to express my frustration bluntly. But thank you for your feedback, it will be taken into consideration as i strive to improve my service to both DX and my clients and may result in changes to better suit general readership.
-
Mario - in my experience *good* developers don't foist unwanted and underdeveloped (c'mon, really, SC2 is very limited in features and has a number of what should have been obvious bugs - do you disagree?) applications on their users - at least, not without the option of running the old system in parallel for a while as things are improved.
-
Yes, SC2 has obvious bugs and yes, it has unwanted features. But it is also the fact that everyone today is resisting any kind of change because that means learning something new which means less time doing stuff from which we survive.
Also take into account today's speed of things. Everything moves way faster. There is A LOT of software out there that get out as betas simply because there is no time to do everything by the book.... -
Also, I quite frequently deploy bugs and unwanted features (which I thought would be great but turns out customer has different thoughts) in my applications simply because we are very small team and clients want changes pronto - they don't want to wait weeks or months for a new release. And because of that I communicate with my clients I fix bugs and because everything is in flow, clients don't get frustrated because they know things will bi fixed.
DevExpress does the same. -
And that is why I'm not all that frustrated. After all SC 2.0 is usefull and you can't say that your business in in stop because of bugs in SC 2.0, that's just plain rediculous.
DevExpress support is still on spot, all my tickets are handled - so there isn't really anything to complaint about. Instead, let's give them usefull feedback and I'm sure they'll make SC 2.0 a great tool. -
The fact that you have to reply over three separate comments is ironic testimony to one of the problems. :^)
How can you 'learn something new' when the functionality simply doesn't exist, or is flawed?
I have also noticed some days pass before DX to respond to SC2 questions.
SC2 is an answer to a question that no-one - at least no customers - seem to have asked. -
As a developer I know that sometimes you have to do a step back to provide more (wanted) features in future. This step back is always painfull, but if you get a better system in the end, I think it is always worth it ... time will tell ...
-
I agree with Mike and Drew completely.
Mario, while you are right about the importance of keeping an open mind on changes, the point in building software is to provide a solution for ACTUAL problems. As far as many customers, myself included, are concerned, there wasn't anything wrong with SC1.
Furthermore, a software's upgrade should be exactly that: an UPGRADE. As in "everything I had before is still there, only it works better and there's a few new gadgets to look up at".
-
Crono, this is not always the case. Sometimes you deploy new features because you need better infrastracture and/or upgrade to new technologies.
For instance, my current business application is "perfect" for customer. It is fine-tuned to it's final details. But it's getting old, hard to maintain, hard to support new stuff and so on. Because of that, I'm moving to XAF. For my customers, new application will be two steps backwards because I won't have time ... -
... won't have time to implement ALL feature of current application. They are not asking for new version, they are perfectly happy with this one and they will hate me for a while because of it - I might even lose few of them. But I have to do it anyway or I might slowly slide off the market.
Because of that I do understand why SC2 came to life and I'm confident it will much better tool than SC1 - it will simply need time to get there. -
SC2 will only improve if DX actually acknowledge their customer's input and act on it. Note there is no reply or anything at all from DX here after 7 days? With SC1.0, direct questions to them usually were answered within 24 hours, if not much less. Problems with SC2.0 can only be addressed by DX - peer replies alone are not helpful in almost all cases.
-
My guess is that SC team is considerably smaller than component team and I'm guessing that pushing 12.1 is their current priority. All my component tickets has been replied within 24 hours and the fact that this ticket (or any other SC related ticket) hasn't been answered doesn't really affect my business in any way, so I'm not concerned. I'm sure they will fix all SC issues eventually and I guess I'm simply more patient and understanding than rest of you.
-
Perhaps reason for this patience is the fact that I was in this situation several times before when I simply had to delay several things because of priorities that piled up. Eventually I solved everything that was delayed, but some of the customers simply had to be more patient and understanding than other. Now role has changed, I'm the customer that needs to be patient.
I will stop playing DX advocate now, no point to further drag this thing. -
Sorry, Mario. I don't see why you did what you did to your customers, and I don't see why DX did this to us. If the customers are happy, you won't "slide off the market." I've got similar issues with my sites, but the customers that are happy with the old stuff will always be able to use the old stuff. I'll turn it off when the last customer leaves. Not before.
-
Actually, there are quite many reasons why would you do that. And no, you wouldn't keep old stuff because of one customer because maintaining old stuff would probably cost far too much to be affordable.
Do you think DOS users asked for mouse? Did we ask for Metro or Unity? Nope. And yet, here we are. Things move one and we adapt. Or we don't. -
The advantages of using a mouse are obvious. I don't think you are seriously comparing a buggy and under-featured web application that previously worked just fine to such a situation, are you? There are also other options to DX components. The comparison to Metro might be a good one though. :^)
I guess we'll just have to see if / when DX actually make changes to SC2 to address user feedback. Fingers crossed it'll be 'soon'. -
Advantages of using a mouse are abvious? :)) Well, why don't you tell that to hundreds of accountants that STILL prefer DOS applications just because data entry is several times faster. You see, it's very individual.
Non-functional search in SC2 was the only thing that was really bugging me (and it's fixed). All my component tickets are addressed - so where exactly is the problem? I didn't notice my business slowed down because of SC2, did you? -
It's still a poor comparison - you don't have to use a mouse even if it's installed, whereas DX customer's have no choice in using SC2.0.
Yes, the change to SC2.0 has negatively impacted my work, and my manager has commented negatively on the change also. You are right though - one could look at the SC2.0 changes (and changes to the installer for 12.1) and tolerate them, or see them as part of a trend. -
I have just discover that the read/unread status is lost even if I remove the 'www.' from address! so on the same pc, same browser at: http://www.devexpress.com/Support/Center
the tickets are 'read' and at: http://devexpress.com/Support/Center the tickets are 'unread'!
i guess it is normal beahvior when use cookies, but this is ridicolous anyway...
You must
log in
or
register
to leave comments
1 Solution
Stan (DevExpress Support)
06.12.2012
Thank you very much for expressing all your thoughts about the new Support Center. I should apologize for the delayed response. I want to share with you that we have not yet made a final decision on how to make this functionality better. I confirm that at the moment the information about read topics is stored on the client. On one hand it is a good idea to store such information on the server, but this may significantly reduce the web site performance and overload the server usage. Not to mention the storage requirements. Please bear with us while we investigate this.
-
Not sure how many users you have, but for 50.000 users with each read 1.000 tickets (which is A LOT), you would end up with 50.000.000 records which needs to save two 64-bit integers, plus index, you end up around 1Gb of data. With today's prices, that's less than 1$.
As for performance, 50M isn't that much, plus, you can load that data async and set read style when data comes back (there is delay now as well).
C'mon, every forum in the world does it :) -
simply change the default action of loading all issues every time we fire up the page: allow us to set filters first, then click "Show Issues". As it is now, it is crazy server-load-wise..
-
Hi Stan,
I appreciate your efforts, and the efforts of everyone else at DevEx, but the excuses for SC 2.0 are piling higher and higher. As Mario said, just how much data do you expect would need to be stored per user? Isn't this how it was done with SC 1.0 ? Was the performance of SC 1.0 "significantly reduced"? Was the SC 1.0 server "overloaded" with too much "usage" and massive storage requirements? I thought DevEx sold high-performance controls that could handle millions of records? -
Like the 'other Mike', I appreciate your efforts and I know I appreciate working with your components every day. But - c'mon - as Mario said, every forum in the world 'somehow' manages to deal with the data / load requirements of marking threads as read and storing it on the server. It is also understandable that merging the forum and ticket system has resulted in this feature being initially overlooked - it's really needed though, please.
-
Guys, I agree that there are several possible ways to implement this functionality. We have not yet thoroughly tested different approaches. My point was that the implementation of this functionality requires an additional join to be performed on the server side and this may be an expensive operation for the server in case of a huge amount of data and a large amount of users requesting it at once. Nevertheless, we will discuss possible ways for implementation as soon as possible.
Is your intention to post an answer to your own question?
- If so, then proceed.
- If you simply wanted to post additional information, ask for further clarification, or to just say "Thanks!", please click Leave a Comment.
- If you wish to edit your original question, please use the Edit button in the Toolbox at the top right corner of that entry.
Facebook
Twitter
Google+