The wordpress app for the iPhone was just released. I’m using it to write this post. The app is pretty nice. I wouldn’t expect any code samples or wordy posts coming from my phone since my texting skills are pretty weak, but it’s a nice app for when blogging on the go is required. The built in access to categories, tags and the live preview are very impressive.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
I’ve been visiting the Yahoo! Design Patterns Library periodically for the past couple of years, but somehow I only now managed to stumble upon UI-Patterns.com. It’s always good to have another resource to help create better user experiences, so I’m glad I found it. The site is very well organized and cleanly designed, making it enjoyable to use (just as you would expect from a site that focuses on UI/UX). If you do any work that involves a UI, you should check out this site.
It must, or I wouldn’t have spent nearly as much time over the last few days fighting with it as I have. He started it!
Ok, maybe it was slightly my fault that I’ve been having the issues I’ve been having. Maybe my expectations were just set too high. I figured the DropDownList could handle whatever I threw at it. I was wrong.
So I found myself in a position recently where I needed a DropDownList to allow users to select an item based on a search. So the workflow is a bit like this:
Now, based on the search term, there is a good chance that multiple items in the list will have the same underlying value attached to them. That’s ok, it’s what is expected of the system. This allows the user to make their choice based on the display and still give the application the value that it needs to get the job done. This seems like something that should be reasonably easy to do, and at the beginning, it was.
The search returns its items and binds them to the DropDownList. No problem. The user can select an item in the list as part of the form completion process and submit the form. The value can be picked up on the server and the app can do what it needs with the data. Also, no problem.
At this point, there hasn’t been a problem. The problems arise when you go beyond simply binding a list of values and having that field as part of a larger form. Let’s look at each problem seperately.
The first problem arises when the form is bound to an exsiting record. When binding the form, the options that were available in the list for the initial selection will be populated again. This puts multiple items in the DropDownList and in this scenario, there are multiple entries with matching values (but different text). Now as part of the binding process, text fields are set, checkboxes are checked and an item (prefereably the correct one) needs to be pre-selected in the DropDownList based on our record. To account for this, the display value from the selected item is stored as well (strictly to put the selection back in this scenario). So we pull the display value since those are unique and use that to find our desired item. Set the returned item to selected and we’re set. But we’re not. Even thought we have picked the item based on a unique property and we know that in the code-behind, only one item was selected, the page will result in an http error letting you know that you cannot select more than one item in the DropDownList. Removing the other items from the list prevents this, but it is not ideal since the original options should be available during an edit operation.
The second problem occurs when you want to perform some operation based on the DropDownList changing. Typically, you would attach a SelectedIndexChanged event handler to the DropDownList and then set its AutoPostBack property to true. So, when I needed this functionality, I followed those steps and it worked. It worked until there were items with matching values in the list. Once that happened, changing the value would cause a postback, but would not trigger the SelectedIndexChanged event handler. I worked around this one with a Page Method and some client-side ASP.NET Ajax code. Again, not an ideal use for my time.
So why are these tings happening? Well, based on everything I have seen happen here, I have to say that the value of each item is important and probably should be unique. In my opinion, the event and method names lead you to believe that it is looking at the Index, or that you can select an item based on picking the right ListItem object. Apparently, at some point, the value needs to be used to complete the setting, change detecting, etc. so it should be treated as a unique key.
My situation is not the most common way to use a DropDownList, but I can’t imagine that I’m the first person that needed to do something like this. Oh well, I’ll come up with a better way to handle the UI in situations like this in the future.
I recently discovered jott.com and so far, I’m finding it to be a very useful service.
If you are not familiar with Jott, it’s a voice based note-taking, communication and reminder service. Once signed up, you call a phone number and use your voice to send email or sms messages, leave yourself reminders, create calendar appointments or even post to a blog or twitter account. Jott allows you to call in and have news feeds read back to you. You can even perform product searches on Amazon by telling Jott what you are looking for. The Amazon results are then emailed to you so you can review them later.
There are hooks in place for other services to integrate Jott and there are quite a few apps (such as wordpress, google calendar and twitter) that are already setup tp work with Jott.
There is also a free iPhone application that works with your Jott account.
At the moment, Jott is free. The business model behind it is unclear, but I’m sure there will eventually be some sort of tiered subscription model or audio ads during phone calls into the service (I could also be completely wrong).
It’s definitely worth checking out.
I’ve worked with quite a few JavaScript libraries over the last couple of years. All of these libraries save a great deal of work and allow you to do pretty amazing stuff, but after a few days of learning and using jQuery… I have to say that it is the most impressive one that I’ve worked with.
jQuery has a code-to-impact ratio similar to regular expressions… lots of power packed into very little code. The big difference (other than purpose) is that unlike regular expressions, jQuery is pretty easy to read and write. The selector syntax makes writing unobtrusive JavaScript a simple task and the number of plug-ins that are available means that most common (and some not-so-common) problems have probably been solved already. All you need to do is download the plug-in and use it on your page. jQuery offers a fluent interface which allows several functions to be run in succession by chaining methods. Condensing 5 function calls into a single line of code not only works, but it is also readable.
As an ASP.NET developer, conflicts with ASP.NET Ajax are a concern, but with jQuery even if there were conflicts (there aren’t any that I’ve encountered yet) with another library, you can call a single method ($.noConflict()) and you have nothing to worry about… they seem to have thought of everything.
It rocks. You should try it. I will write more informative (and more organized) posts on jQuery in the near future… stay tuned.