We are currently an Infragistics NetAdvantage Select customer and have been for a few years. Their controls are ok but not what I would call great but the time invested in learning them to date is the main reason we stick with them. We use both ASP.NET and Winnform controls.
As we are due to renew, we are considering DevExpress as an option as they seem to offer much of the same functionality.
For anyone that has made this move fro mInfragistics to DevExpress, how have you found it? A step forward or back? Pros and Cons to doing so?
My company is using DevExpress and we are very satisfied with their suite. We have never used the Infragistics suite, so I can't talk about the process to switch from Infragistics to DevExpress.
Generally, I find the DevExpress controls very easy to use and implement in our applications. Some controls have a small learning curve like the DevExpress TreeList but it is not a huge issue.
One thing I dont like with some of their controls is the property "Properties". This property is used to set additional options to the control.
Per example to set the max length of a textedit (textbox of devexpress) :
textEdit.Properties.MaxLength instead of textEdit.MaxLength
So, their controls are great and have a great look but I think the main quality of DevExpress is their support. You can ask a question on the support page and you will receive a answer within one day, maybe two days if the question is complex.
So, if you are not statisfied with Infragistics, try DevExpress. You can download a trial version so you have nothing to lose.
I will second that you should give Telerik a look. Their support is top notch in the industry. They give you good real world examples and their documention I feel is second to none.
I took on a contract with a company entrenched in the controls you're considering and I wouldn't use them if they were free.
The reasons I make this statement is their documentation in my opinion was bad. When I spend money on a RAD type control suite, it's to make my work easier and faster to production. I found in some cases it was easier to just figure out how to make built-in controls do what you want versus trying to figure out the problems I was having with their controls.
Their samples are kind of like Microsoft samples used to be. They are fluff based for Tech sales to show at a seminar "how easy something is to setup" but in real world if you used the techniques and monitored viewstate and traffic their examples generated, you'd be less than impressed.
I didn't have an account to submit support tickets but I had 4 over the course of a month submitted through the account holder and to my knowledge didn't get an answer back on any of them. (That could have been a break down with the person I had to go through but I doubt it.)
When it comes to Telerik's, Rad controls for Ajax, very seldom I can't figure out what I need to do by either looking at the sample Visual Studio sample web solution that get's installed combined with their documentation.
Good luck in your search and even if you don't consider Telerik, I would strongly suggest you look for other options.
Slightly unrelated but you might also want to evaluate the Telerik controls. We have been using them for years. Exceptional controls and support. And their controls work with ASP.NET MVC as well.
Just a happy customer here.
Not related to controls, but with DevExpress suite you get superb VS addins for free - CodeRush and RefactorPro.
Like Francis, I haven't made the move from infragistics to devexpress, I started with devexpress. I can speak to the learning curve. Depending on the controls you're going to use, and how you intend to use them, there can be very little learning curve.
The data manipulation controls (xtragrid, xtrascheduler, xtracharts, etc.) are extremely easy to use when binding to a database. Less so when binding to persistent objects. Their XPO, oddly enough, isn't as easy/intuitive as it could or should be when databinding though also not incredibly hard.
The major benefit for me was documentation. Their documentation site as well as their tutorial videos are top notch and really get to the point without using trivial, nor overly-complex examples.
As Francis said, the response time on tickets, and the (usual) clarity and detail of the replies - they often include small projects showing what you're supposed to do, or will alter your project that you submit with a ticket - is second to none imo.
Moving from Infragistics to Devexpress is tough! I have been using Infragistics for past 2 years as a Windows and a Web developer and now I am using Devexpress at a different place.
It is slightly difficult for the developer to use the Devexpress control due to its versatile properties. If you take a example of grid in DevExpress (in case of Windows) there are 2 parts:
The main display part and
The view part so you can manage them during the binding
On the other hand there was no such thing in Infragistics, so it was plain and simple to use.
Similarly there are lot of such difference between Infragistics and Devexpress controls.
Now What I feel is if you are interested in having some complex functionality with lot of tedious logic then Devexpress is good for you! Or if you want to keep the things simple with decent functionality then Infragistics is good for you.
So as you know it is very difficult to tell which one of these is really superior - we have to choose them based on our own requirements.
Stick to Developers Express. They have much better upgrade path and almost all breaking changes are in written.
I have been using them since 2003 and still ahven't found a better match.
I migrated from Infragistics to DevExpress. Will never go back to Infragistics as their objects are much heavier and performance is not too great. Documentation is terrible and their examples are very juevenile. Infragistics data grid inline editing (Excel like) is a nice feature which is not available in DevExpress. Other than that, data grid, master, detail setup, data grid dropdown list declaration and other feature are much more streamlined in DevExpress.
I have been using Telerik RAD Controls since several years. I am very satisfied with the ASP.NET Ajax and WinForms controls. I have not used DevExpress or Infragistics controls before but I had a look at both when I took the decision to use Telerik.
This is probably too late, but as I found this post while asking the same question I thought I would add my comment with respect to Telerik. I have previously used Infragistics, which I found OK, but I thought the performance wasn't great. Recently I worked a contract with a company who were using Telerik for Winforms and what we discovered was that there were a number of bugs in their controls. There support was great and they were quick to respond to questions or comments, but unfortunately most of the time when we raised a question on why something wasn't working, the answer was that it was a bug in their control. also their documentation states explicitly that their controls are not intended to be inherited, so while building your own custom control off the top of their control seems to work in most cases, it isn't recommended.
Related
I am looking for a reporting and database contols solution. This post is not a rate the control but what has your experience been when using it.
I had a look at Telerik, DevExpress, Syncfusion and a few others. I have downloaded a copy of each and tested each for a week or so. However these arent cheap when I make the investment I would like to base it on othera experience as well as my own feel for the tools.
I had read all the post on SO and many other sites. Many outdated so wanted to know more recent experiences.
DevExpress looks great and seems to be what im lookig for however from what ive read their controls are coded and very differet ways. WPF is apparently very bad. I could be wrong though and please correct if i habe been misinformed.
Everyone seem to be happy with Telerik.
I will probably be customising later on so source is important. Winforms will be used. But would like to migrate to WPF and/or ASP.Net later. This is client requirements.
thanks in advance
You should list down your expectations from a third party suit.
Also its better to compare individual components rather than the whole suit.
I have lot of experience with devexpress#winforms, but the learning curve is quite steep.
I don't like the layout controls. Rest of the controls are pretty slick. Reports and Charts are good.
Support is also quite good.
I'm working with DevExpress scheduler for WinForms right now, and I can say only praises for this component suite. Everything is accessible easily, customizations are very easy; but to be honest I still haven't done any major customization, so it could be possible that 95% cases are easy, but that 5% is impossible (not sure, don't have that much experience with DevExpress). I would just say that they are much better than Infragistics WinForms suite.
Also reporting suite (XtraReports) is well known as a very good solution.
Since most of the people having to change from Office 2003 to 2007 in their office are confused, it amuses me if there is an objective reason for abandoning the good old interface of previous Offices.
It would also be nice to have some backing facts when people ask about rationale of change. For example I would be interested in:
Was there a study telling that new users without any prior Office knowledge can adapt or use the new interface more efficiently?
What are the strong points of the new UI from a designer perspective (which function is more accessible than before; which important pieces of information are more apparent? etc.)
For more answer than you probably want, you should read this excellent series of posts by an Office UI developer about why they decided to build a new UI for Office 2007. The basic reasons boiled down to:
The old, toolbar-based UI was already overcluttered, and there was no place to put new features.
It was difficult for users to discover the features that were already there.
Jensen Harris, one of the Office 2007 team, wrote extensively about the design process, the information they used to guide the design, and how they evaluated the designs they came up with: see http://blogs.msdn.com/jensenh/archive/tags/Why+the+New+UI_3F00_/default.aspx for the main set of articles and the rest of his blog for additional info.
One thing I think worth keeping in mind is that the ribbon UI isn't designed just for existing users.
I personally think that it IS more user friendly once you get to know it (it makes sense to see something visually rather than bury it in a menu), and from the anecdotal evidence I've seen* many new users prefer it.
We just started rolling it out at work, and while there have been grumbles, there have also been many positive reactions to it.
Microsoft published a paper on this. I haven't read it.
http://download.microsoft.com/download/1/6/f/16fd06b3-7059-4e21-adf4-9fbdcb9a2853/MsftOfficeUIAnsResearch.pdf
I guess the new ribbon UI provides a more natural and better user experience than the old one. People usually complain coz they are so used to the old way of doing things.
An example of bad design in the old UI is in the "File" Menu, you have the "Exit/Close", which does not make sense, as with the windows xp taskbar "Start" button, that contains the "Shut down", notice how windows vista/7 has the windows logo instead of the "Start" word.
Just my two cents.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
What comes first? After the design has been outlined and approved, should a designer create pages in HTML and then hand them to a developer to add code? Or should a developer build simple pages that work and hand them over to the designer?
I've always done the latter, but recently worked with a designer who built an entire site in HTML and handed it to me to make it work. I found it saves a lot of time for 3 reasons:
The developer doesn't have to create all the form fields and rudimentary layout.
The designer doesn't have to rework all the "ugly" pages into something attractive, instead starting with a clean site which is faster.
The code isn't accidentally broken by the designer. I've found designers are more likely to break the code doing their work than developers breaking the design adding the backend functionality.
In short, if the designer does his work first, there's very little rework. I just make what already looks great actually work.
So which is best practice? See other plusses and minuses?
EDIT: Assume both designers and developers are already in agreement on the proposed design.
Wireframe mockups and visual aides are a great way to elicit requirements from end users. Giving the user something to look at and see helps to drive the design to where it needs to go instead of developers just doing the guesswork.
Also, UI design does affect your code. I think the biggest myth that we buy into as programmers is that we can just build a business layer and then spread the UI on like peanut butter. It never happens this way, so I am a big fan of having designers work with users early on and often. Having a visual design to work against is like TDD for the UI, and it helps to drive the process downwards.
Best practice is to try it both ways, see which way works best for your organization, then do it that way.
Occasionally try it the other way to see if anything has changed.
That way you get a solution tailored to your situation without worrying about ephemeral transitory things like "best practice".
As you can probably tell, I'm not a big fan of rules being handed down from on-high. Don't get me wrong, if something proves to be an advantage, I'll use it (agile, for instance, since it focuses you on immediate deliverables). But it has to be proven in the environment you work in, otherwise it's just something that worked for someone else.
I think it depends highly on how your views and code behind are set up. Some people will put a lot of logic into their views and others will have little to none. It will eventually just come down to your specific case.
In most cases, I agree, it will be easier to create the HTML first and include the back end programming later. It is essentially making a specifications document for you.
Once you've got your storyboards all worked out and approved, it's probably more natural to do more detailed "sketching" at the HTML level first. But I guess I'd also try to decouple the design and code as much as possible, so that the developer and designer can work somewhat in parallel. Two ways of decoupling are XHTML/CSS and "unobtrusive Javascript".
The developer and designer can work out the skeletal XHTML page structures they'll need from the set of storyboards. The designer then can use static mock pages to develop the CSS style sheets and explore the artwork. Meanwhile the developer can focus on generating the XHTML structures without style information. The big advantage (and goal) of CSS was to separate page structure from page appearance.
Another avenue to explore are "unobtrusive Javascript" frameworks like jQuery, whose goal is to separate the page's behavior from its structure, again making it easier for the developer and designer to work in parallel. By parallelizing these activities, it would be possible to incrementally deliver versions of the final product, both in form and in substance.
I would definitely go with designer first. If the coder does the pages first, he's forcing a design on the designer -- particular for a multi-page form.
Depends on the type of place you work at and the skill set of your teams!!
I worked for a Design Agency for many years where designers ruled as they brought in the biggest revenue stream and the web work was an add on to the services.
We worked very closely with the designers to make sure the designs met requirements and we not to off spec. The designs were a lot of the time used as sign off (don't get me started!!) and not much could changed once agreed by the client. The designers were also not that good at HTML,JScript,CSS etc so this was left to the developers to implement.
So in this case design was always done first which worked well, even if it was for the wrong reasons.
Well, assuming that the designer produces high-quality HTML and CSS (which is far from obvious, btw), the question boils down to: do you have 100% control of your HTML or not?
If you use a CMS, or a framework that likes to produce lots of its own HTML (like ASP.NET), then you have no choice. Trying to make the output match the designer's HTML is a pointless headache. You'll be better off with your original method.
However, if you produce all of the HTML by yourself (using PHP or, say, a lightweight framework like Django), it's better for the designer to produce the HTML first, for the reasons you mentioned.
Small nitpick: I disagree with reason #2. CSS-based design is all about taking "ugly" (that is, bare and functional) pages and making them attractive, without even touching the HTML. If the developer writes decent, semantic markup, it should be pretty easy for the designer to add his design on top (well... with some HTML hacks added, like for round corners and the like), since this is what he should be doing in the first place.
We are developing an ASP.NET application. We retained an outside UI design firm, and for the most part have been very pleased with their work. Their "deliverable" to us was clickable screens -- Visual Studio solutions with ASPX files, images, master pages, etc. The screens were not connected to any data source. They had dummy data so that we could see how the UI worked.
One problem we've run into is that our developers are used to using Visual Studio design mode. The pages we receive from the UI firm have problems sometimes when we pull them up into design mode. The consultant's developers coded these screens without using design mode.
We assumed they'd be using design mode, but this wasn't specified in the contract. Was this too much to assume? Is there a lot of ASP.NET development work that never goes through VS design mode?
Third party edit:
Suggestion: people responding to this question should specify which
version of Visual Studio they're
using, as Microsoft trashed the code
base that was in the VS2005 and
earlier designers, and replaced it
with the one they purchased when they
purchased the Expression products. The
two are totally unrelated, and the new
one is far better. - John
Saunders
The more and more you work with Visual Studio, the less and less you rely on Design Mode. Complicated UIs tend to make the design view look atrocious.
I (and peers) never use Design Mode, for two reasons:
I learnt in VS 2003 not to touch Design Mode because your HTML was managled by VS. (Not anymore though since 2008, but once bitten ...)
It can take ages to render.
Much quicker to drag-drop from toolbox and hand-code.
I actually find that ASP.NET developers that do use the designer to be quite rare. The Visual Studio designer is notoriously bad at generating clean markup.
I never use design mode, probably because it used to mess my markup so much. Plus I do a lot of dynamic rendering, so there is no point. And I use exclusively CSS for formatting, I don't want VS messing around.
Many never use it, because of bad past experiences. I have found little trouble with Design mode in VS2008, when using modern controls, which are up to date and have good designer support.
On the other hand, because of the earlier problems, a lot of custom server controls do not have good designer support, so are much less useful in design mode now that the earlier designer code base has been replaced with a good one.
I almost never use design mode. It typically creates ugly HTML, and call me anal, but I really like to have clean HTML. If that means hand-coding it, so be it.
I prefer doing it manually, I like to have control.
If I want to look at the result, F5.
I almost never use design mode. For me, the biggest reason is because I learned web design/development in Notepad, so I was used to (and comfortable) working with code. Design mode makes me uncomfortable because I'm never sure exactly what decisions VS will make with regard to HTML, etc. Additionally, I can't imagine that a developer would learn nearly as much about ASP.NET and VB/C# using design mode.
The only time I use design mode is to automatically configure a GridView or something like that like.
Design Mode is taking quite a beating here, but let me point out that it is great for learning about new controls. When you are new to ASP.NET, or are using a new library of controls, Design Mode is a godsend for two reasons:
You can modify properties on the Property Editor and see them reflected immediately. This is particularly true for list-container type controls, where the entire layout may depend on one property. Running your application five times to see all five layouts is very tedious.
Controls with complex behavior (and lets face it, thats why you're using a control, right?) often have a lot of configuration built into their Smart Tags. Notice the little [>] arrow in the top right of the control? Click it. It'll probably help you out big time. This is particularly true for configuring DataSources, whose syntax is very meticulous.
When I was first learning to use Telerik controls, I relied heavily on the Smart Tags they provide, which are very robust and complete. From that, you can see what kind of ASPX markup is generated and learn to work outside of Design Mode. I am a learn-by-doing kind of guy, so I much prefer this approach to looking at the documentation when using something for the first time.
I'm using VS2008, and I never use the design view. I find the code view to just be easier and more responsive than the designer.
Y'know, I never even realised I use the source screens 100% of the time. I usually develop in VS2005.
Whenever I do actually open the design mode, it's by accident, and I try and hit the source view before it renders. I've never been impressed with the design mode, and find it slow as well as adding a lot of unnecessary markup. I also find that intellisense and the properties window mean that I don't need a GUI to develop.
The design mode can also be a nightmare when you're trying to add any nested items. Because we've been developing for a customer using IE6 we've been using tables for formatting so we don't need different DIV definitions. Just clicking in an empty cell can be difficult, and resizing a column can take far too long.
For things like Template Fields in grids, I don't even know how I'd go about setting this up in design view!
Having said that, design mode every time for windows apps!
Design mode is getting better and I'd say that it's likely to become more prevalent as time goes on and the design mode tools continue to improve. I design all my components for design mode, but I still do the large majority of my code by hand - it allows greater control of code layout and doesn't end up creating an auto-formatted mess that I then have to dig through to figure out what changes need making. I know that in future my components are likely going to be used by developers that do most of their design by drag/drop and it's easier to cater for that now than have to come back and do it after the event.
Granted I'm doing MVC stuff, but I never use it - I "grew up" with PHP and code editors, and it still does me just fine.
I'm using two different versions of .NET (2003 & 2005). Some of the forms that were written in 2003 can no longer be edited in 2003 and the installation requires that they be maintained in 2003, so I use KEDIT to edit those forms.
Some of the forms in one application are too big for the .NET editor and I prefer a strong editor anyway.
I have no problem working in design mode. One exception is asp:Repeaters, which are not supported, or GridViews which tend to override my manual column definitions.
The other is if VS tries to do a full project scan if I rename a control, and then fails.
We primarily use the code view. The design mode is quite buggy we've found in VS 2008. XML controls tend to barf random character sets out for some reason, and VS will generally run slow whilst trying to render everything on screen. I mainly use the code-view.
Traditionally WYSIWYG designers produced poor code and render CSS and #INCLUDEd files poorly so they were of limited use, so developers tended to code by hand. In addition, these tools allowed you to go a certain distance without real knowledge of what you were doing, which was fine for web tutorials and personal homepages, but as soon as you wanted an extra degree of control you became unstuck - when meant you had to resort to looking 'under the hood' anyway.
Although tools have improved over time, many developers are so comfortable with hand-coding that they all but forget about the Design View - I certainly can't remember last time I used it. I'm sure there are a number of situations where such tools could be genuinely useful, but we are doing fine without and don't want to be bothered with figuring when & where such features can best be used.
Our UI is complicated and it is impossible for us to use design mode with VS2005.
The only time I have touched design mode is to do a quick and dirty prototype or an internal app.
How often do I not use design mode? 99% of the time.
I'm working on an VB6 app and I'd like to get rid of the old Sheridan controls and replace them with built in VB6 controls.
However, some of those controls have some nice properties, like the ForeGround on the ssCommand button. The standard VB6 command button doesn't have a foreground property.
I know that VB6 potentially has lots of other controls that I can enable but I'm not clear on which ones are fairly "standard" (i.e., not third party controls). I'd like to keep this app as plain vanilla as possible and not create dependencies. (Yes, I know that any components for VB6 have long sense become abandonware. I just anticipate a higher level of compatibility from a built in VB6 control since it was probably used more and thus "pounded on" more and it's flaws would be more known.
Any suggestions?
In my opinion threed32.ocx (the Sheridan SSControls) should be dropped because it has a number of problems. It's no longer supported, all the controls grab the focus when made visible including panels and frames (!), it's hard to upgrade to VB.NET - there are more. For my company these are strong enough to outweigh the extra functionality it gives - we're droppping it from all our programs.
Some of the discussion is too pessimistic IMHO. VB6 is not abandonware yet - we're not all doomed - though no doubt we will have to upgrade the code one day. Microsoft say:
The VB6 runtime is supported for the
full lifetime of Windows Vista,
Windows Server 2008 and Windows
7, which is five years of mainstream
support followed by five years of
extended support.
Microsoft are still supporting a number of their VB6 controls. Check the online list and only use the controls that they do support. These are the standard, tested, supported controls Clay is looking for in the original question. If you want to use third-party components, check whether they are still supported by the vendor. I would agree that you should always think hard about how much benefit you're getting before you introduce dependencies, which can be a support headache. If you use special components, try to wrap them in an abstraction layer. It might save some pain later if you need to replace them. You can hide all the fancy features except the ones you really need.
A final word - don't use the ForeColor property in the SSCommand. There's no corresponding BackColor property, so you have no guarantee that your special foreground colour will contrast with the system background "button face" colour. Just like Raymond says.
Sometimes a little ingenuity will go a long way. For instance, I wanted my VB6 command buttons to have custom background and foreground colors even though that violates the 'Windows standard look'; however, I wasn't ready to put out lots of bucks for that functionality since my projects are not commercial. So I tried a few things and finally settled on what, for me, is a very workable solution: I overlaid my buttons with label controls and now have multi-colored buttons that look absolutely authentic. I can control the button colors programatically to reflect various states of operation even going beyond a simple 'click / no-click' combination. One of my applications uses a group of five buttons which assume various colors depending on the combined button values.
I think keeping an app as 'plain vanilla' is a worthwhile goal. Certainly simplifies deployment.
I'd say the best way to find standard components for VB6 is to install VB6 (plus service packs) on a clean machine. All available components will be standard.
If you're unable to do this, for each checked Component or Reference in your project, research the file (dll, ocx, etc) referenced.
In this scenario, you're in for an uphill battle. Trying to eliminate dependencies on long-dead components is probably a good idea, but in a case like this, you're already on an abandoned technology. It's clear to me that rebuilding the app in more modern technology (EG, .NET) is not viable, so that leaves you with a limited set of options.
Replace the Sheridan controls with the existing VB6 controls which are a closest match, then update the code accordingly. This will be an intricate, difficult process, and you are correct in assuming that in many cases there won't be a match -- Sheridan (now Infragistics) built their business by providing UI capabilities which weren't in-box on VB6. In many cases, your UI will have to be seriously adapted to support this.
Consider writing "good enough" versions of the controls in VB6 yourself, or even .NET (the latter using advice from this StackOverflow question).
Consider replacing those controls with (likely long-since abandoned) open source VB6 controls. Google will be your friend here. The reason I recommend this route is that many UI elements have been represented in ActiveX over the years, as open source -- and if they're open source, you can at least "support yourself" on them.
I know you're going for a plain-vanilla out-of-box VB6 deployment, but for some UI elements, that may not be feasible. If you can rebuild your UI to #1 specs, then go for it, but you may have so much work cut out for you there that it might be time to consider going for the gusto and rebuilding on a modern, supported platform.
I've been through this, and you'll be long at it, and IMHO not very happy with the results.
VB6 can't be a long term solution anyway. Why not leave them in there? Yes they're abandoned, but I used them and never needed support anyway. (Plus it went to hell after the first time they were bought.) My experience was that they are pretty darn reliable. I'd just go with it, and if you have spot problems, provide spot workarounds.
I have to disagree with your reasoning. One might expect better support from someone whose living depends on you being a happy customer.
It's also likely to be the case that any vendor depending on VB6 sales is likely so go broke soon.
Why bother? If your product works then don't worry about it. I have found the Sheridan controls to be quite solid. If you're not experiencing any issues with them then leave them alone.