Description: As part of a university assignment we have designed a new interface for KCall. We have posted a prototype of KCall using our new interface which you may test and try. Remember it's still a prototype, and not all functionality is implemented yet. During the design phases we have also received numerous suggestions and feature requests which we believed were very useful though we did not have the time yet to implement all of them yet. Please be patient as more functionality will be made available. We will try to integrate our results back into KCall as good as possible.
Thanks,
Arend van Beelen and Thijs Vermeulen. University of Leiden, Netherlands.
WHAT SHOULD WORK: - Outgoing and incoming calls. - Caller ID recognition. - Address book integration. - Most of the interface.
WHAT DOESN'T WORK: - Actual sound during a call (at least I wasn't able to get it to work, using SUSE 10, hopefully someone can report better experiences). - Transfers. - Call List / History. - Be prepared for plenty of bugs.Last changelog:
It would be nice if you could add a textbox or something similiar, which could be hidden or not, and would display useful information that would help find the causes of problems with calls.
kcall 0.5.2
cat kcall_interface.patch |patch -p0
patching file kcall_part.rc
patching file kcallgui.h
patching file main.cpp
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file main.cpp.rej
patching file kcallgui_part.h
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file kcallgui_part.h.rej
patching file kcallgui.cpp
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file kcallgui.cpp.rej
patching file kcall.desktop
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 17.
2 out of 2 hunks FAILED -- saving rejects to file kcall.desktop.rej
patching file kcallgui_part.cpp
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file kcallgui_part.cpp.rej
patching file Makefile.am
whats version of kcall should use ?
whay you dont add "full patched kcall src" in download ?
why README not found in kcall_interface tarball ?
any one get success with this patch ?
The patch is against the current Subversion checkout of KCall. We didn't put time in creating real packages as it's still a non-functional prototype anyway.
Greets,
Arend jr.
I think the Delete contact button:
X Contact
V Contact
is misplaced; it should either stay in the main toolbar or be located just below the main list of contacts.
Its not clear how the Numpad is got to, but the overall layout is very nice... what is that, a dash or underline beneath the 0 key?
A customizable image for the contact is very nice, even nicer if it could be shared that is I may want to transmit my image with my contact info to someone else?
The X cq. V button you mention is not related to the Contact. It actually is the button for showing/hiding the Numpad panel. Hopefully this is more clear when the interface is actually being used.
Greets,
Arend jr.
It would be great if it can be used from other KDE apps. So please alow for DCOP interface.
Looks very good. Hope you release alpha versions as early as possible as sugestions are kind of hard until you have it right in front of you.
What kind of database are you going to use? Perhaps SQLite and Mysql should be considered as SQLite will be useful for those working as stand alone, but for others working in a team, a real SQL server might be best.
I would like to see a recording feature in kcall. I think it would also be cool to have a way to let the computer give you a call to somewhere else through a text2speech software controlled by a schedule, lets say I would like someone to give me a call and remind me something. It would also be nice to have a way to filter the call in such a way that a speech recognizer software could try to recognize something. I know this type of software (speech recognition software, voice authentication, etc) does not currently work that well but it might do in the future. And this could be a start. Is it possible to add any of this features when developing the GUI?. I only mean if it is possible to add a way to redirect incoming and outgoing sound to some other application through the GUI. As for the screenshots I have seen they really look nice. Good job. Don't worry too much about the features I have just proposed that might be a little too far from what you had in mind. Thanks in advance for developing for all of us.
Hi!
Thanks for your suggestions. I'm afraid though they won't make it in our design anymore, as I feel they're a bit beyond the scope of this project. However, I suggest you take a look at the Asterisk project (http://www.asterisk.org). It sounds like many things you suggest could be better implemented at the server-side (I would even be surprised if Asterisk doesn't already provide some recording functionality). Of course then some hooks to that functionality could be implemented in the end-user interface, like the way we want to provide support for voicemails at some point.
Greets,
Arend jr.
Hi!
Thanks for your suggestions. I'm afraid though they won't make it in our design anymore, as I feel they're a bit beyond the scope of this project. However, I suggest you take a look at the Asterisk project (http://www.asterisk.org). It sounds like many things you suggest could be better implemented at the server-side (I would even be surprised if Asterisk doesn't already provide some recording functionality). Of course then some hooks to that functionality could be implemented in the end-user interface, like the way we want to provide support for voicemails at some point.
Greets,
Arend jr.
*This* is the way to create and develop an easy-to-use interface, and your mock-ups are simply great...moreover you're not just throwing some screenshots saying "IMO it would be better this way" but your are providing a complete document with all the rationals behind and working actively with the developers of the program. This is simply awesome and the way to go for everyone that cares about usability in KDE.
If you are going to do a new work after KCall, may I suggest you the KDE printing system? It has got all the power but definitely needs a hard work on UI as you are able to provide.
Again, great work!
Well, I vote for interface number two in your pdf document, but I would like to suggest a few changes. Most people will include the information for calls in their contact meta data, but for those instances in which you have to use the number pad, I would use a dropdown panel from the bottom of the form to hold the number pad. Since it appears your using qt I would suggest going with a shpe changing form to implement this change. That way, your interface would remain clean and you'd have plenty of space to display user information, but when the number pad was needed, it would be availible with the push of a button. The number pad is really only there for dramatic effect anyway, since a user could easily enter the number in the Dial text box, but for people that are new to using the software the number pad is a nice touch. Navigating through speech menus can occur, but it's not somthing that hgappens everyday, so I'd still argue that the number pad should appear on a drop panel (Panel that slides out from the bottom or left/right side of the form). I also prefer the tool buttons on top (as shown in the second display) as opposed to the side, because then the form is left/Right hand neutral. That's also why I sugested having the number pad slide out from the bottom of the form when visible. Your very last screen shot in your pdf file appears to be overly crouded. Stick with interface number two. I hope these suggestions help.
Hi guppetto!
thanks a lot for your suggestions!
I do wonder, what exactly do you have in mind for such a dropdown panel for the numpad? Would it be a panel that floats over the phone book panel when expanded? Or would just the entire window become bigger when it expands? Maybe you can show a simple drawing to illustrate it :)
I'm also curious as to what extent left or right handedness influences the direction in which you operate an interface... isn't it more dependend on the direction in which you read?
About the icons, probably we will just need a few of them. But an open call to the icon designers might be a good idea :)
Greets,
Arend jr.
You should ask the community for some custom icons for your project. Hold a contest requesting the support of some of the icon designers that post here. Give away t-shirts or memorabilia and in exchange you'll get visual tastyness forr your project.
I read your proposal and it seems very well-considered and quite strong. I would love to support your work!
In my experience and for good reason, devs can be touchy. I think you should be very careful to communicate early with the kcall developers and talk to them first before releasing anything major.
I like to suggest one strength of the Open Source model is the openess that promotes utter transparency. For example a public mailing list for KCall that would help track discussions and show how certain decisions were arrived at and implemented...
Hi athleston!
thanks for your reaction. I can assure you that we provide all our work during all stages to the KCall developers. We also get useful feedback from them, and we try our best to meet up to their standards :)
Greets,
Arend jr.
Ratings & Comments
19 Comments
Great improvements! Way to go.
It would be nice if you could add a textbox or something similiar, which could be hidden or not, and would display useful information that would help find the causes of problems with calls.
Please make sure that "Transfer Call" and "Blind Transfer" get different icons.
We know, we know... the current icons are just placeholders.
kcall 0.5.2 cat kcall_interface.patch |patch -p0 patching file kcall_part.rc patching file kcallgui.h patching file main.cpp Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file main.cpp.rej patching file kcallgui_part.h Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file kcallgui_part.h.rej patching file kcallgui.cpp Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file kcallgui.cpp.rej patching file kcall.desktop Hunk #1 FAILED at 1. Hunk #2 FAILED at 17. 2 out of 2 hunks FAILED -- saving rejects to file kcall.desktop.rej patching file kcallgui_part.cpp Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file kcallgui_part.cpp.rej patching file Makefile.am whats version of kcall should use ? whay you dont add "full patched kcall src" in download ? why README not found in kcall_interface tarball ? any one get success with this patch ?
The patch is against the current Subversion checkout of KCall. We didn't put time in creating real packages as it's still a non-functional prototype anyway. Greets, Arend jr.
I think the Delete contact button: X Contact V Contact is misplaced; it should either stay in the main toolbar or be located just below the main list of contacts. Its not clear how the Numpad is got to, but the overall layout is very nice... what is that, a dash or underline beneath the 0 key? A customizable image for the contact is very nice, even nicer if it could be shared that is I may want to transmit my image with my contact info to someone else?
The X cq. V button you mention is not related to the Contact. It actually is the button for showing/hiding the Numpad panel. Hopefully this is more clear when the interface is actually being used. Greets, Arend jr.
btw, the line under the 0 is an underscore, but actually represents a space. Hopefully we can make that more clear somehow...
It would be great if it can be used from other KDE apps. So please alow for DCOP interface. Looks very good. Hope you release alpha versions as early as possible as sugestions are kind of hard until you have it right in front of you. What kind of database are you going to use? Perhaps SQLite and Mysql should be considered as SQLite will be useful for those working as stand alone, but for others working in a team, a real SQL server might be best.
I would like to see a recording feature in kcall. I think it would also be cool to have a way to let the computer give you a call to somewhere else through a text2speech software controlled by a schedule, lets say I would like someone to give me a call and remind me something. It would also be nice to have a way to filter the call in such a way that a speech recognizer software could try to recognize something. I know this type of software (speech recognition software, voice authentication, etc) does not currently work that well but it might do in the future. And this could be a start. Is it possible to add any of this features when developing the GUI?. I only mean if it is possible to add a way to redirect incoming and outgoing sound to some other application through the GUI. As for the screenshots I have seen they really look nice. Good job. Don't worry too much about the features I have just proposed that might be a little too far from what you had in mind. Thanks in advance for developing for all of us.
Hi! Thanks for your suggestions. I'm afraid though they won't make it in our design anymore, as I feel they're a bit beyond the scope of this project. However, I suggest you take a look at the Asterisk project (http://www.asterisk.org). It sounds like many things you suggest could be better implemented at the server-side (I would even be surprised if Asterisk doesn't already provide some recording functionality). Of course then some hooks to that functionality could be implemented in the end-user interface, like the way we want to provide support for voicemails at some point. Greets, Arend jr.
Hi! Thanks for your suggestions. I'm afraid though they won't make it in our design anymore, as I feel they're a bit beyond the scope of this project. However, I suggest you take a look at the Asterisk project (http://www.asterisk.org). It sounds like many things you suggest could be better implemented at the server-side (I would even be surprised if Asterisk doesn't already provide some recording functionality). Of course then some hooks to that functionality could be implemented in the end-user interface, like the way we want to provide support for voicemails at some point. Greets, Arend jr.
*This* is the way to create and develop an easy-to-use interface, and your mock-ups are simply great...moreover you're not just throwing some screenshots saying "IMO it would be better this way" but your are providing a complete document with all the rationals behind and working actively with the developers of the program. This is simply awesome and the way to go for everyone that cares about usability in KDE. If you are going to do a new work after KCall, may I suggest you the KDE printing system? It has got all the power but definitely needs a hard work on UI as you are able to provide. Again, great work!
Well, I vote for interface number two in your pdf document, but I would like to suggest a few changes. Most people will include the information for calls in their contact meta data, but for those instances in which you have to use the number pad, I would use a dropdown panel from the bottom of the form to hold the number pad. Since it appears your using qt I would suggest going with a shpe changing form to implement this change. That way, your interface would remain clean and you'd have plenty of space to display user information, but when the number pad was needed, it would be availible with the push of a button. The number pad is really only there for dramatic effect anyway, since a user could easily enter the number in the Dial text box, but for people that are new to using the software the number pad is a nice touch. Navigating through speech menus can occur, but it's not somthing that hgappens everyday, so I'd still argue that the number pad should appear on a drop panel (Panel that slides out from the bottom or left/right side of the form). I also prefer the tool buttons on top (as shown in the second display) as opposed to the side, because then the form is left/Right hand neutral. That's also why I sugested having the number pad slide out from the bottom of the form when visible. Your very last screen shot in your pdf file appears to be overly crouded. Stick with interface number two. I hope these suggestions help.
Hi guppetto! thanks a lot for your suggestions! I do wonder, what exactly do you have in mind for such a dropdown panel for the numpad? Would it be a panel that floats over the phone book panel when expanded? Or would just the entire window become bigger when it expands? Maybe you can show a simple drawing to illustrate it :) I'm also curious as to what extent left or right handedness influences the direction in which you operate an interface... isn't it more dependend on the direction in which you read? About the icons, probably we will just need a few of them. But an open call to the icon designers might be a good idea :) Greets, Arend jr.
You should ask the community for some custom icons for your project. Hold a contest requesting the support of some of the icon designers that post here. Give away t-shirts or memorabilia and in exchange you'll get visual tastyness forr your project.
I read your proposal and it seems very well-considered and quite strong. I would love to support your work!
In my experience and for good reason, devs can be touchy. I think you should be very careful to communicate early with the kcall developers and talk to them first before releasing anything major.
I like to suggest one strength of the Open Source model is the openess that promotes utter transparency. For example a public mailing list for KCall that would help track discussions and show how certain decisions were arrived at and implemented...
Hi athleston! thanks for your reaction. I can assure you that we provide all our work during all stages to the KCall developers. We also get useful feedback from them, and we try our best to meet up to their standards :) Greets, Arend jr.