I want to take multiple inputs from user in multiple steps.
Which approach is better? Multiview or Wizard control?
What is the basic difference between them. can any body guide me in it.
Thanks
I would go with a Wizard control, as long as the experience is informative and usable. It is a typical process and I would guess most users are familiar with the approach.
Before heading straight into the development it would be ideal to map our the flow and information you want captured in each step. Then decide how persistent the wizard should be - can the user come back to the same place when saving a draft, do all pages need to be completed before saving, how are transactions handled.
For tips on design you can look over some Smashing Magazine articles.
Related
I am looking for a library to facilitate a nice UX for displaying a reservation calendar for a small bed and breakfast place. I would like to be able to show a calendar with maybe two views, being a high level 'year' view, showing high and low seasons, and basic indication of existing reservations, and a 'month' view showing more exact reservation details and allowing a user to submit a reservation request by using buttons or context menus.
I am in a very early part of the life cycle for this project and am looking for suggestions here rather than specific solutions, but what libraries and components are out there that I can look at and draw up a shortlist from?
For the sake of simplicity and speed of execution, I would consider the Telerik controls. If you're able to implement this in Silverlight then the calendar/schedule control pretty much gives you everything that you're asking for, really:
http://demos.telerik.com/silverlight/#ScheduleView/FirstLook
They also have a fair amount of configurable controls for .NET and JavaScript as well:
http://demos.telerik.com/aspnet-ajax/calendar/examples/functionality/specialdays/defaultcs.aspx
If you just want a solution that doesn't require integration into the .NET code then the jQueryUI JavaScript library may be useful. It merely takes data coming back from the page load or a service request and displays it for you:
http://jqueryui.com/demos/
Hope that's helpful.
Ext JS could be a viable option, then you could use a scheduling product that I have created. This demo could be pretty close to what you need: http://ext-scheduler.com/examples/html5/html5.html (try it in FireFox or Chrome for best experience). Integrates easily with ASP.NET too.
Other options would be FullCalendar (jQuery), ASPxScheduler by DevExpress.
I have an Administrator that needs a dynamic form generator with layout capabilities on an ASP.NET page so that they can add, edit and change layout of questions that will be filled out by users whose responses will be saved into the database dynamically. The format is very important as there will be an offline piece that will be generated using Adobe Acrobat and both forms need to be very similar in format. The online portion also needs to be fully printable so that the end user can keep a copy for there personal records. Does anyone know of any ASP.NET controls, free or otherwise, that I could use to complete this functionality? Or what would be the best technology to solve this problem?
Not sure I see a question. This is more of my opinion of what you should do:
Im working on something similar. My form generator had a LOT of complicated fields and data to handle and I decided to go with silverlight. I very happy now, despite the learning curve, and the madness async api, because it would have just been hairy to do it with asp.net, pure asp.net with postbacks would just be bad UX and then putting ajax in between would've just been scary.
If you have great Ajax/asp.net experience go with it, but if not, Id suggest silverlight. I got up to speed pretty quick.
Let's say I'm on a list page and I
page to, say, page 10. Then I select
a record on that page and redirect to detail
page. After that, I click on the edit
to redirect to the edit page.
After I update the record I'm redirected back to
the detail page. I, then, press back
to go back list to continue my browsing from
where I left off. The key here is
where I left off in the list which is
page 10.
What is the best way to handle this?
Initially, I put a hidden field called page number in each of the webforms and pass it along with the querystring back and forth. Seemed like a lot or a bit redundant checking the querystring on each page and passing it.
I was wondering if there are some other ways. for instance, I've been reading about a separation between the UI and the presentation layer is a good idea (for larger scale apps). To me I understand it as all click handler events will yield control over to the presentation layer which is just a plain class?
Is this correct? Also, is the presentation layer suppose to implement something particular? I know this could probably be saved in session but could someone humor me and show me how to use a presentation layer to handle this (I know it would be overkill but is it possible?)
I don't think there is THE best way. Everything depends of what you achieve to do, ie. the requirements of the whole project.
After all, according to the description, I don't even understand why are you having three pages to do a single thing. By the way, ASP.NET data controls handle mostly everything for you, so you don't even have to ask yourself how to do this (except if you have serious reasons to avoid ASP.NET controls).
For example, a simple <asp:ListView /> will let you list items page per page and show details when a single item is selected. Edition of an element is also quite easy.
What you are asking for is well... large and could span multiple blog posts to give a complete understanding of UI Design Patterns.
I have a small example of MVP with Asp.Net here: What is the best way to reuse pages from one website in another?
However, it is not exhaustive. If you really want information on this you should do some looking into a framework such as WebForms MVP, or ASP.Net MVC.
Check out ASP.NET MVC. It is a framework which goes on top of ASP.NET to do the separation between the presentation layer and business layer.
For simplicity, what you are describing is a very good example of the perfect place to use Asp.Net Dynamic Data.
It's incredibly easy and powerful, and easy to modify once you dig into it a bit. I'd start with the videos here: http://www.asp.net/dynamicdata
I've been using this more and more on every project, for at least the simple CRUD portion of it. I really can't express how much I love this tool now that I'm used to it.
In my application, I have a situation wherein the users will need to have the flexibility to customize the UI to a certain extent. The following are some of the customizations that is being discussed now...
Change Label text associated with the with Use Input controls
Mark a control as Mandatory/Read only/Hidden
Assign a regular expression for the text box
Are there any recommended design patterns for my situation? Seems like I need to store all these in a database and worried about the performance impact if I have to read every element from the database for every page.
Thanks,
Harsha
I would look at some of the open-source CMS or portal systems written in ASP.NET and see how they are doing UI customization (if they are).
Phil Haack has some insight at the following article:
Scripting ASP.NET MVC Views Stored In The Database
http://haacked.com/archive/2009/04/22/scripted-db-views.aspx
Apparently it's not an easy thing to do in ASP.NET. It's easier to do in ASP.NET MVC, because the markup is cleaner and you can control it with jQuery.
The overall concept you are going for is not easy to have system wide, however the specifics you stated are fairly easy.
You'd have to setup some fields in a database for those values and then on the page load set those values on the page load. Pretty trivial from a 'how to'. Which your question shows that you 'get'.
Now unless you are using an Access Database :-), I don't think you have to worry about the performance hit. But if truly concerned, put some caching logic on those values so you only have to hit the database once. Though, be aware this will store the values in memory on the server, so if you are working with a very minimal hardware this could be an issue as well.
A few guys on our team are of the opinion that every web page in the application should be a web user control. So you'll have all of your html + event handling in the Customer.ascx, for example, and there will be a corresponding Customer.aspx page that contains Customer.ascx control.
These are their arguments:
This practice promotes versatility, portability, and re-usability.
Even if the page is not re-used right now, it might be in a future.
Customer page might need to move to a different location or renamed sometimes in a future and moving user controls is easier.
This is a recommendation by MS for new development.
Is this really a recommendation for new development? Are there any drawbacks to this strategy? I agree that it's nice to have a user control on hand if the need arises, but it seems to be an overkill to do this to the entire application "just in case we need it later".
1, 2 & 3: Doing anything because "you might need it later" is a horrible strategy.
http://c2.com/xp/YouArentGonnaNeedIt.html
4: I have never read this and seriously doubt MS has ever said anything like this. Maybe some random article by one single person who has an MS tag or was an MVP or something, and a gullible junior dev took it as Gospel Truth.
Seriously complicates client-side script as the NamingContainer jiggery will prepend _ctl0 etc to everything sometimes.
I don't think MS ever recommended it. Request links to MSDN documentation.
Typically by the time your are done implementing something, and it is sufficiently complicated, you'll find a lot of "gotchas" when ever you try to "reuse" it. A good example is relative links in the user control that no longer work outside of their path.
Users don't need the ability to add/edit/delete Customers on every page. Indeed, you start to get into caching issues if you have these types of controls on every page. For example if on an Invoice page, you add a Customer, will the Invoice control be updated with the new Customer? All sorts of inter-control operability issues can manifest. These issues are hard to argue for, because of course, everyone's user control will be perfect, so this will never happen. ha ha right.
See if they can come up with an example where moving/renaming a user control actually saved time, instead of making it more complicated. Draw up an actual example and show the pros/cons of each.
Personally I'm not a fan, I think it adds a layer of complexity to the application that is not strictly necessary at the early stages. If you need to reuse a component that you had not previously thought would be reused, refactoring it into a user control at that point should not be very difficult.
I came across an application in .NET 1.1 that was written like that once. Someone must have heard that same misguided "best practice" and taken it for the absolute truth.
I agree that it adds a level of complexity that's mostly not needed. I usually find usercontrols more useful for something like portions of a page that are repeated on several pages. If you think you'd reuse the entire page... why not just use the original page?
I also don't understand the moving/renaming argument. It's not that difficult to rename/move a page. If you do what your colleagues are suggesting, you'd end up with a customers.aspx page that contains nothing but an orders.ascx file? I see more potential confusion/errors with that approach than by just renaming/moving a file.