We’ve been doing a lot of work integrating VoIP into Spark using Jingle and SIP (see Thiago’s blog post), so of course we wanted to gather ideas from some existing user interfaces. The result? “Ahhh, my eyes hurt!” In my not so humble opinion, we found more people getting softphone UI’s wrong rather than right. For your entertainment, I gathered together a visual tour of some of the clients we found.
One UI paradigm came up again and again, which is to make the softphone look like a physical object. I can imagine the discussions as this decision was made over and over again by various implementors – “people know how to use their real phones, so we should make our softphone look like one.” Check out the following screenshots:
[blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/officeserv_softpho ne_middle.jpg|officeserv_softphone_middle.jpg][blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/scrshot_softphone. png|scrshot_softphone.png]
How a designer ended up with the examples above is beyond me. They’re pretty hideous looking, waste a lot of screen real estate, and worst of all assume that users are so dumb that they need something that looks exactly like a real phone in order to figure out how to use it.
That brings us to a related category of UI designs. In these, the designers give up the idea of exactly duplicating a real telephone, but still preserve a tenuous connection by creating softphones that look like devices you could pick up and hold in your hands:
[blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/softphone.png|soft phone.png] [blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/zebra-softphone.pn g|zebra-softphone.png][blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/softphone-unlimite d-advance.jpg|softphone-unlimited-advance.jpg][blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/softphone_gr.jpg|s oftphone_gr.jpg][blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/sj-softphone.jpg|s j-softphone.jpg][blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/dialer_v1_big.png| dialer_v1_big.png][blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/softphone3.jpg|sof tphone3.jpg][blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/softphone4.png|sof tphone4.png][blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/softphone5.jpg|sof tphone5.jpg][blog post|http://www.igniterealtime.org/blog/wp-content/uploads/2006/12/xtensoftphone.png| xtensoftphone.png]
These designs are a bad idea as well. When you’re making a physical device, you create buttons for people to push with their fingers, keep the screen small to hold down costs, etc. Applying these same constraints to software on a computer (with a mouse and large screen) just doesn’t make any sense. Why not show a list of people that the user recently called? A text area to type in is a lot faster than clicking buttons on a dialpad, so why not emphasize that? I could go on and on with more examples.
Not every VoIP client we found was bad. Skype does an ok job, and we like a lot of what we see in Gizmo. In a few weeks, we’ll have the first version of our own softphone in Spark polished enough to start showing screenshots. At that point, we’ll welcome feedback on whether we’re as off-base with our UI as so many other sofphone creators seem to be.