A while ago I created a drag-over check box list which allows you to check many check boxes in a single gesture. Do you think it is viable and usable on the web where people might not know how to use it. The default behaviour still works for the individual check boxes.
1 - The idea
The idea is nice and can probably be used in professional applications where you have direct contact with users and can explain them how things work, but not necessarily on public websites where users don't want to RTFM and are just looking for familiar behaviours. Unless it was just a sample exercise or a control meant to be included it in a control pack, it violates the YAGNI principle ;)
2 - The implementation
You certainly noticed that the implementation is buggy (at least on IE7 and FF3.1B2). Sometimes, a gesture above all checkboxes will select all of them but one or two. Moving the mouse over the div's above or below the list will stop the drag (I know it's a "feature", but it's not very user friendly). I Checked the source code and to be honnest, while it looks pretty neat, I just didn't want to deal with it because it is plain javascript. Don't you know that...
3 - Possible improvements
...you can write less and do more with a javascript library, typically jQuery. I would completely rewrite this control as a jQuery plugin. It will provide you with a lot of tools to make your code much easier to write, maintain and extend. Just try it, you'll love it. This is from a technical point of view. From a user point of view, try to make you control as familiar as possible, like what Angela suggested, windows explorer : a nice selection rectangle, the ability to use shit + click, or something like that. Finally, remember that for many windows checklistbox users, "selected" and "checked" are two different things.
The demo definitely needs a few enhancements to make it even a little bit useful (although I am not sure if it would be enough):
Allow the dragging to start somewhere that is not a check box.
Allow selection by dragging over the labels as well.
This problem seems similar to the action of selecting multiple files in a file explorer like Windows Explorer. Maybe it can work like the action of selecting multiple files by dragging a rectangle shape around the items to be selected (select one corner, drag to the other corner)? This has the advantage of being similar to an interface element that people may already be familiar with.
For some reason I can't open your link (it says my ip address was blocked). But I think what you're looking for is what I already did in jquery, I uploaded a plugin which I basically ported from crossbrowser.com's dragcheck functionality, it was to be found at http://plugins.jquery.com/project/dragCheck but currently the jquery plugin site is being revamped and my plugin has disappeared. I'm trying to see if they're going to put it back up or if I have to create a new project again...
Anyways until we get that worked out you can see a demo here: http://jsbin.com/ibihi
Related
We need to get rid of DevExpress Bootstrap Controls for ASP.NET Core from project.
What would be the easiest/cheapest/feastet solution?
To simply rewrite everything with a different framework like Angular/Vue/React?
Maybe there is a known framework/method of migrating to DevExpress ASP.NET Core Controls? Or to something else?
How many controls were used from DevExpress?
If you only used a few controls, then you only need a few replacements.
I would not call purchase of some controls from DevExpress a whole "framework", but that of only purchasing some controls to use with your project.
So, does the project use 3-5 or 50 of those DevExpress controls? (by using, I mean DIFFERENT kinds of controls).
If you only used a few, say like their GridView, then you would only need to find a replacement for their gridview control, or simply use the built-in one, and fancy it up with some css, and addtional options. (I would make a user control).
So, you want to determine what the controls used did, how many different controls were used, and then find some controls that have a great look and feel that you like.
Their grid controls are VERY nice, since they have some "really" nice filter options for the header of that grid control.
So, you need to find some control replacements, but how many did the project use will quite much determine scope here.
So, in place of say their tab control, then consider using the jQuery one. As noted, I would wrap say the jQuery.UI tab control into a user control, so then you can just drag + drop in that jQuery.UI "tab" control in place of the devExpress one.
Same goes for the multi-select combo box (dropdown list).
So, either you cobbile together some replacements of your own, or you find some replacemetns, or you buy some more controls from another vendor.
The challenge and issue will of course be that each of their controls has a specific object and event model.
However, that's not really any different then say if you started used sweet-alert, and now want to replace sweet-alert say with some jQuery.UI dialogs.
I would say that the real challenge of replacing their controls is often not so much finding a replacement, but finding something that has a great look and feel. The main huge wonderful bonus of the devExpress controls tends to be their look and feel. In other words, they had someone with REALLY good taste in terms of look and feel.
I mean, for years I used the ajaxtoolkit. (free, open source). it was and still remains a fantastic set of controls. The pop dialog, the tab control, the multi-select combo box, the HTML editor?
They are all great, but their HUGE downside is not the features, but the controls from that free toolkit look like something from the 1980's!!!
The popular jQuery.UI? Same thing, the controls look ugly and something designed by a un-employed rodeo clown living in a trailer park.
There is a HUGE but BEYOND huge reason that bootstap is so popular.
Know the answer?
Why of course bootstrap is popular for ONE big HUGE massive SIMPLE reason:
Bootstrap has a fantastic look + feel. (zero other reasons for bootstrap being popular!!).
If you ever hired a graphic artist to re-work the look and feel of your web site? Guess what? Their resulting work and suggestions will look like the default of bootstrap!!!
So, someone in the print and graphic design industry or someone with VERY good talent and great taste created the bootstrap system. So, when you use bootstrap, then you get fantastic looking results, results that normally would take a full time graphic artist on your staff.
Regardless, we are wondering off topic here.
The main issue you have to determine is how many controls were used from devExpress. Most of their controls do follow a similar object model as the base controls found in asp.net webform controls.
So, for example, jQuery.UI controls has a great set of features (a great set of UI components), but they look way too dated and old fashioned.
The issue you have is not that you want to replace some of the devExpress controls you used, but how much work it would be to replace say a dev-express "gridview" with another different grid control. Every single one of those controls used will not only require you to spend HUGE amounts of time finding a replacement, but I think the LARGER issue is finding something that don't look like it was created by someone living in mom's basement, or by that drunken un-employed rodeo clown that does not belong in our industry.
your issue is not finding some replacement controls, your issue is how much code and money (time and resources) you have available to replace those controls.
You can no more change a bunch of code in c# to then using say client side JavaScript can then you take some Pascal code, and covert that code to vb.net code.
There no more a replacement for those controls from dev-express then there is deciding tomorrow to re-write some server side code in vb.net to now being client side JavaScript code.
In fact, what I am quite much telling you?
How the computer and IT industry has worked for 50+ years has NOT change one bit, and it not change one bit if you decide to rip out some existing controls and replace them with different controls.
Its possible you are asking for something you never seen, never heard of, and thus are imagining some magic wand here, but those don't exist in our industry either, do they?
As I noted, for quite some time, I used the AjaxToolKit. Turns out that jQuery.UI has near EVERY the same kind of controls available. But, the massive difference is jQuery.UI controls are client side ones, but worse yet, they don't work the same as the AjaxToolKit ones. In other words, there is a nice "tab" control in AjaxToolkit, and there is a nice tab control in jQuery.UI. So, they both are tab control, but THEY are VAST different in their operations, how you use them, how they work.
However, both the jQuery.UI and the AjaxToolkit tab control?
My gosh, do they look like crap.
At least the jQuery.UI one can be easy bootstrapped styled.
Again, note how we not really now back to a JUST having a control replacement, but one that looks VERY nice and VERY tasteful out of the box, and a control that should take zero efforts on your part to obtain that great look and feel.
Want to know what product has those great looking controls and great look and feel out of the box?
the DevExpress ones!!!
What is the best approach to make an SPA (AngularJS) Accessible (for screen readers etc)?
I have little to no experience with the aria specification, and I wonder if it will at all work on a single page application.
What are the common pitfalls when developing?
How do one debug and test the accessibility when developing?
This could cover a broad swath of issues here. So I'll go through some of the basics in the hopes that it starts you on your way, the common pitfalls, as it were.
Firstly, like the commenters said, yes, you need to make sure ARIA tags are employed correctly. So, say, if you wanted to expose a div as a button, you'd have something like this.
<div id="mysuperflashybutton" ... role="button" aria-label="Super flashy" tabindex="0"></div>
This button when selected by a screen reader will be called "super flashy button", so you don't need to put button in your aria-label attribute. There are more complex examples out there, but that illustrates the basics of it, pretty much. Role, aria-label and tabindex will be the most prevalent ARIA attributes you see.
Tab-indexing elements that you want screen reader users to click on is vital to this. Set tabindex to 0 to include it in its default location on the document. If you don't want it to necessarily normally be reached by people using keyboard navigation, set it to -1. This means it's out of the normal tab order, but can still be navigated to if you want to put the user's focus there manually through javascript/jquery .focus().
As mentioned, sometimes you can assist keyboard navigators/screen reader users by moving their focus for them. An example would be if they click a button and a menu appears. You could do something like this to put them on the first link of the menu:
$('#linkmenuactivator').on("click", function () {
$('#linkmenu').find('li:first a').focus();
});
I know that's in JQuery, I'm not familiar with AngularJS but my brief view makes me think it's more of a ViewModel controller as opposed to something UI specific like JQuery, but correct me if I'm wrong.
Live regions can be used if you're doing funky things on screen that will make no sense to a screen reader user. You can write text to the elements in these regions to put the information out textually. The easiest way to do this is to use a role of alert or status, for important messages or generic status updates respectively. These roles make your element a live region by default, and any text changes in there will be reported to the screen reader. So a quick example would look something like this:
<p id="ariastatusbox" ... role="status"></p>
Then later in JQuery (taking the example of you loading a document and fading it in when you've got it):
$('#maincontent').fadeIn(function () {
$('#ariastatusbox').text('Document loaded');
});
This will let the screen reader know that the document is loaded and ready to be read on screen. Live regions can be slightly tricky, but they're a powerful beasty if you can master them.
Finally, as to accessibility testing, there's a few options. Something I recently stumbled across is Wave which appears to be an online testing tool. It looks good from a first glance, you could give it a try. Another option is to grab a screen reader yourself and give it a go. I recommend NVDA which is an open-source (so therefore free) screen reader. It's my screen reader of choice and is pretty damn good. The synthesiser it comes bundled with doesn't have the nicest voice, but there are other options, or you could turn off the speech output and view a textual display of what it would be saying using the Speech Viewer. A final option is to ask for accessibility testers to take your app for a test drive. For consumer products or things in those brackets, blind people and other users of accessible tech may well volunteer to do it if asked. For more business oriented apps that you might not want out in a public forum, there are several organisations that can consult on issues of making web applications accessible.
This is by no means a comprehensive manual on accessibility, I was hoping to really kickstart you in the right direction. For a bit of a deeper look, try looking at the ARIA roles documentation (all of it will help but the code is under the definitions heading), and on from that the ARIA States and Properties documentation. They both can be a little dry, but also have the full list of everything you can use ARIA wise. Google should be able to yield some tutorials, too, I hope.
I hope this helps get you started. Good luck!
I've been playing with WPF for some months now, and I quite like it.
But one of the things I don't get is why MS doesn't put a little more effort in helping developers by supplying basic controls, and I need to get this off my chest :)
For example, I figure most applications somewhere will need to let you edit some properties - for configuration or whatever.
What would be the most used types in a proprety-grid editor ?
text
numbers (byte, float/double, int, etc)
colors
....etc.
So why isn't there even something as simple as a control to edit numbers ? Like a generic NumericUpDown control that allows you to type in numbers (no text, no pasting invalid input) or spin them up/down according to some given rules (decimal, floating point, min/maxvalue) ?
Why isn't there a generic colorpicker, so people get the same user-experience in every application ?
Why isn't there a standard implementation of a SearchTextBox, a BreadCrumb-control, or all these other standard control types users have gotten accustomed to the last 10 years ?
(..but at least they DID have the time to implement a generic splashscreen - because everyone knows that greatly increases user-productivity....)
The well-known ideal is always to give people the same user-experience over different applications. So even if some of those controls would be easy to make - it would be preferred to have one version over different applications.
I see people all over the internet trying to do the same stuff over and over again.
Okay, so MS started a WPF Toolkit project on Codeplex that tries to implement some controls, but only did so half-heartedly and is completely dead by now (last update of the roadmap dates back to Mar 21 2009).
The result of this is that a lot of people starting a WPF-project end up spending a lot of time on trying to figure out how to create some generic controls and get really frustrated.
Wasn't the mantra "Developers, developers, developers!" ..?
/Rant
Because its ridiculously easy to make these in WPF. With WPF and silverlight microsoft's focus is on a core framework that makes many tasks (such as stylable controls) dead simple. Tools are more important than prebuilt controls. They are focusing on the NEXT thing rather than a better Winforms.
I think Microsoft - and some people responding here - are forgetting about the most important part of this post :
"The well-known ideal is always to give people the same user-experience over different applications. So even if some of those controls would be easy to make - it would be preferred to have one version over different applications"
Just Google Image Search on "WPF Color Picker" ( http://www.google.nl/images?q=wpf+color+picker ) and you'll see this idea go down the drain.
That's exactly what i thought at the beginning with WPF..
But afterall, a NumericUpDown is easily created with a cutom usercontrol, same for all the controls you will ever need, you can create it by yourself in (almost) no time, or grab some implementation googling around, and then you can still customize
I think they provided the very basic implementations for the UI elements and leaved all the custom stuff to developers and who need custom stuff, if they would have done a generic color picker, maybe it wouldn't have had all the functionalities that anyone would ever need
There are a lot of 3rd party vendors out there that provide powerful custom controls (editor, navigation, grids, menus, property grids, ...).
It's - in general - cheaper to buy from them than to rewrite your own (when it fits your need of course).
Historically, Microsoft has always encouraged a rich "component-based" eco-system around what they provider out-of-the-box features. This has been true from the beginning of component programming (VBX, OCX, ...) with Microsoft technology. This is arguable, but that's the strategy :-)
I find that the winform tool tips behave very erratically. They seem to randomly decide to do nothing, show up or disappear when I perform the same hovering/clicking/etc actions.
Is there some pattern that I'm missing? Do I just not understand the UI technique to bring up a tooltip? Is this a common problem? Do people actually expect tool tips to work this way?
Tooltips display automatically. That's a bit of a problem, the native Windows control has counter-measures in place to avoid displaying tips too often, potentially wearing out the user with info that has been shown frequently enough. Not exactly sure how that rate limiting is implemented, accumulated time is a factor (like 60 seconds), possibly also the number of times it was displayed.
The SDK docs do not document the implementation details. There is also no message available to forcibly reset the rate limiter. I do think that passing another control in the Show() method resets it.
All and all, it does mean that the ToolTip control is really only suitable to act as a traditional tool tip. It doesn't work well as a 'dynamic label'. which is your alternative, a Label control with BackColor = Info. Albeit it not quite the same because you cannot easily make it a top-level window.
We were building out the next version of an in-house thick-client application using WPF/Prism (Composite Application Library). As we were nearly done with the client our team was put under new management and shortly thereafter:
We were then directed to drop the Prism framework to keep things simple. This includes not using any type of Inversion of Control.
We were directed to build out the WPF application without using MVVM or similar; and more along the lines of a traditional WinForm application. The idea is that if a developer sees a control in Visual Studio’s designer view, then (s)he should be able to click on the control and see exactly what it's doing without having to traverse through a view-model (or similar).
We have now been tasked with building out the WPF application using one primary Window, use a Frame Control to contain the content, and use a Ribbon outside of the frame for the menu items. Reason we were provided to use Frame Control:
a. We will show a view in the Frame with a Page (not a user control) and then load the page in the Frame.
b. When a new view is to be shown in the Frame, the current view (Page) will be closed/disposed and the new view (Page) will take its place in the Frame.
c. When a developer looks at the Page in design view, (s)he will be able to click on any control and see exactly what is being done.
Given the restrictions of 1 and 2 above, we’d like to present another method of building out the application that:
Can be presented as an alternative to using the “Frame Methodology” (item 3 above) but still provides the same type of functionality.
Does not use MVVM (see #1 and #2 above).
Provided the direction we’ve been given, any suggestions as to an alternative we can present? I’d request that the responses be kept on the professional level and thank you in advance.
I'd personally try to argue to use Martin Fowler's Presentation Model. (That's a joke, btw...)
Basically, you're being given a restriction that says "Use WPF, but don't use any of the features that make WPF usable." It really sounds like your requirements are such that you would be much better off explaining, reasonably, the advantages of patterns like MVVM.
It sounds like the weird requirements are really boiling down to this:
The idea is that if a developer sees a control in Visual Studio’s designer view, then (s)he should be able to click on the control and see exactly what it's doing
If that's the main issue, and the reason you're avoiding MVVM and other similar patterns, I would seriously take the time to educate the management. Looking at a Command, by name, instead of an event, by name (which is what you see in the designer) is really no more difficult.
However, in a large scale application, the separation of concerns is key. Even a properly designed Windows Forms application requires a clean separation of concerns - but with event based programming, this becomes much more difficult, especially from the designer. If you try to develop a large scale, clean, application using an event approach, you'll have event handlers, but those event handlers will all eventually need to delegate their work to a separate component.
This is actually adding an extra level of effort, from an understandability and maintenance point of view, on top of what you get with MVVM. With MVVM, you only look to the ViewModel, which is very discoverable.
BTW - The "rationale" for using a Page instead of a UserControl doesn't make any sense. You can do exactly the same thing you're describing with UserControls... The only reason to use a Frame and Page is if you want to take advantage of navigation, in which case, you can't dispose the old pages directly (or they get regenerated constantly). Also, the navigation tools probably wouldn't be used with a ribbon - the two conceptual models are quite different.
There are criticisms of MVVM which may be applicable to your project; however having unreasonable dictates of programming methodology is always a recipe for disaster.
One of the reasons that we have frameworks and spending time building layers and separation is to avoid the coding mess that always results when you can "simply click on the button in visual studio to see the code that is being executed".
There may not be a way of achieving what you've been asked to do without something similar to MVVM, because anything that has an architecture may well be labelled as being too similar.
However I have been using a system for many years that provides simple inter-object plumbing currently called Emesary you may want to read my C# .NET Emesary walkthrough.
But basically it allows my buttons to be implemented thus:
private void addButton_Click(object sender, RoutedEventArgs e)
{
GlobalTransmitter.NotifyAll(new Notification(NotificationType.CreateRecipe));
}
This may be an answer to your problem. It's under hyped, small and so simple but it just works well.
I've achieved a solution to the second question by using a Window, a user control for the ribbon bar (the user control contains the listview), and another user control for the Frame part. This second user control obvious is built using other user controls using a very simple view class. All views and controls are connected using Emesary.
As a school project I had to develop a WPF client which allowed for multiple people to make use of it at the same time. And I used Pages. My verdict: Save yourself a huge amount of effort, and use UserControls instead.
Sometimes the Page Navigator (which you'll use to scroll through) tends to bug out and cause you a lot of problems. Maybe it was my crappy coding, but who knows?
Though I must say, the control being called "Pages" is somewhat misleading... I went "Eureka!" when I found them, and swore at them thereafter.
I totally agree with #2 (MS bigs take note!). It would be cool if you could double-click a Control and it would take you straight to its command (or event if its command is lacking). However till then, make sure that you organize your Views and ViewModels in separate folders.
Having a dual screen (or a very wide one) will allow you to have two instances of VS open on the project, one focused around the View and the other around the ViewModel (my personal choice was having Expression Blend on the View).
Although not a very big application, I managed to convert my project to proper MVVM (ie. ViewModel for every UI element, RelayCommands and Mediator) in a matter of days, so once you understand it it's not too complicated to implement. Plus, there are tools out there (such as Josh Smith's RelayCommand and Marlon Grech's Mediator - totally free, by the way) which make MVVM half as difficult, and twice as powerful.
Using WPF without MVVM is like trying to eat rice without a fork. You'd be better off using WinForms if you're not going to take advantage of what WPF has to offer. My 2 cents.
I wish I could say your management is totally wrong.. but I cannot say that as it will not be the most accurate truth. I guess that the main reason to the changes you described is either because the new manager is not comfortable with the concept of MVVM being the new messiah of UI development or/and another reason could be the cost of educated sophisticated developers vs. cheap developers which can be instructed to get the things done as fast as possible, a concept which is widely known as lean development.
So, putting all I wrote so far under "not what you asked for", here is what I suggest:
you can still use object oriented pure approach, meaning you can have a model object which already have method to show UI information. so every object will be a window derived object, that way you will loose on SOC but you still going to be OOP/OOD.
But LOL, The next phase will bring you to seperation of model from view in order to not repeat the same code in many derrived windows which relay on the same data... so your management will endorse MVC/MVP as good solution .. and the distance from it to MVVM is kinda of short if they want WPF.
Conclusion: you will have to teach your manager why it is better to go for MVVM, unless the project is very short.