| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Currently, when we want to call someone, we navigate to a contact, then click the call button. Similar action happens when we want to SMS them. For IM we go to another app, but its usually the same type of behavior, find name, start IM. I propose that Symbian would do away with all of those vectors and have a contacts system that acts like this:
If you will, instead of the person trying to figure out what type of communication works best, the person on the other end sets the rule, and then the initiator's device "respects" that rule and by chooses the best communication method. I also envision a system like this being able to receive/post the status messages of social networking services and corporate IM systems. Further more, the mobile's social object book (Contact list with additional components which may or may not be connected) learns through location and time-based information the types of communication the user most likely will receive and by default presents these modes. So, it learns that when you are at the location tagged "Work" and on the days Mon - Fri between the hours of 8 to 17 (5pm) and within a few weeks of this pattern begins automatically setting your mobile to the right profile, and diverts communications as you need them without your intervention.
Posted on 08/15/2009 04:49 AM BST
, Last Modified on 05/25/2010 05:28 AM BST
Comments (16)
Addition: I do think its also possible to get a status of a caller (available, on the phone) from the cell network, but not sure if this is more of a network polling piece, that's then cellular service controlled, or if it is definitely something that could be used to better tune these actions into behavior-bending concepts.
0
0
I think this is an excellent example of the "thinking outside the box" (please forgive the cliche) that we need. We need to look at the user need and design the contact model around that. But the traditional method is a different app for each different technology (one app for telephony, another for SMS, etc.). And we still haven't properly incorporated things like location-knowledge into our usage model. All around, this is a great example of the sort of thinking we need - the sort of the thing I was looking for in the "fully converged device" thread. It definitely gets my vote.
(I hope you don't mind: I also moved it to the Personal Communications category - it seems to fit better there than in Data Communications. BTW I realize it's a bit ironic having categories defined around Technology Domains when I argue that we should use multi-technology thinking more often, but this category structure helps in the assignment of "expert" roles.)
0
0
I don't mind the move to a new area at all. It took me a while to figure out which category to post it in to begin with, its cross-functional - at least according to the topic areas here. I think that there's just much more that can be done with contact lists other than the reproduction of "a little black book." Thinking about how we use devices, and how we think about connecting with others, the model for a contact list/address book - and any other PIM apps - should follow that moreso than follow the paradigms of times and technology no longer used.
0
0
So let me throw something more into the mix. Extending a bit on Antoine's idea for having status-based personal communication... Imagine something closer to a true "Personal Assistant", well beyond a PDA - maybe call it a Mobile Personal Assistant. Many of us would like to have a good secratary, 24/7, to look after our calendar, handle incoming calls, contact people for us etc. Well, why not? With a bit of imagination, the "fully converged device" could go a long way in this direction...
Of course, none of this is even slightly new in the secretarial field. This is a theme that I often notice in such discussions. We've actually had all these solutions for decades (centuries?) as standard methods of working, but it's somehow an "innovation" that nobody has yet thought of putting into our electronic "personal assistants". Obviously it would take a considerable amount of work to get the implementation to work well enough. And it would need careful development and testing to avoid it being annoying rather than helpful - I sure don't want an irksome animated paper-clip (remember him?) popping up at inappropriate times saying "You appear to be in the lavatory ...". But, when we get it right, it would be a huge improvement - a mobile device that behaves appropriately when we are busy and when we are free.
2
0
Ah, good ideas never die, they always come back around. Back at the other end of the decade I built a remarkably similar messaging client for M$'s other mobile platform - It used your 'buddy's' (!) status to decide whether or not to SMS, IM or email. It never saw production as we'd asked the MSN guys to come up with a lightweight protocol for MSN that would be suitable to use over SMS-WAP. Let's just say, that they never really 'got it' I only mention it, as I have a niggling suspicion that a patent was filed for using online status as a measure for message routing, which would apply here (They probably have no idea they have it, if it was ever granted). And on the subject of patents, Nokia [is/were] progressing a patent for using the urgency of a message as a metric for routing of messages, which you may stumble onto as an obvious extension to the idea presented here. Still, I agree with Lawrence, this is exactly the sort of clever, integrated, application that is so sadly lacking from 'smart' phones
0
0
I think that something like this would work best if all of those misc. fields in an address book could be mapped to various serivces. If you will, instead of downloading a Fring, Truphone, Google Talk application, I'd simply either install a plugin, or this framework would already be built into the Contacts app, so that the funcitonality would be gleaned directly from the services layer. After that, its just a matter of inserting and authenticating your credentials, and going forth to just communicate. At least that's what it looks like in my head. Technically, I have no clue what this looks like on the backend :)
0
0
New-ish version of this idea: a two-stage address book: Within most of our address books, there are two types of contacts: our contact information (emergency and business card uses) and the contact info of our contacts. I wonder if its possible to literally split the contacts/address book up along these lines and thereby enable better contact management. First thought separate your personal information from everyone else's. Your personal information serves two purposes: emergency identification information for you, and a digital business card that you send to everyone else. So I propose this:
Secondly, the infomation that you keep from everyone else. This is pretty much the opposite of the profile above. You either have your own local versions of that contact information, or have (through a plug-in interface) have downloaded-to-local/synced with 3rd party social networks/Exchange a contact list. Then there's that idea/option of linking to a contact. So you get this request to add someone to you address book, but its just a linked contact. When they are online, you get notfication and what service; when they are on the phone you see that their icon/avatar has an overlay for that. If you will taking the idea of a social address book, but separating it along the lines of something a bit more personal and mobile. Thoughts?
0
0
Slapping my own hand here as I see part of this idea as something that can be implemented with the idea posted of taking the mobile web server as an openID server. So then the profile that is created when the device starts up is then able to not only serve as a point of information for emergencies, but could also be one's online identity management place.
0
0
Are there examples of applications/services that do similar to this idea already? I know there is Fring and Nimbuzz, but outside of Palm's webOS, I cannot think of another.
0
0
Oooh, someone was listening: http://www.getaddressbook.com/public/angelbackup/index.html
0
0
Sounds like where Google are going with Wave; i.e. communications where the primary key is the people communicating not the format/channel being used. A no-brainer (at the idea level at least).
0
0
Pretty much. Our devices and networks should be smart enough (now) to be able to determine what is the best communication method. We should just want to communicate. Where this takes off though is in those various streams of information - social objects and how we connect them. Essentially making social object out of each contact, and those connections are just done in an intelligent manner. I think in this mindset, such a paradigm is easy to use, and ultimately more effective for users and developers alike.
0
0
Good ideas :) This behavior should add another point. When we can have the geolocalization of someone, you should be able to know if it's daytime or nighttime for him, it could be sad to wake up a friend because he's on the other side of the world ;)
Last point to show, the Mode should permit to change our status on chat too. If I switch my phone to Meeting Mode, my chat must become "busy - Meeting" automatically !
0
0
I agree on the ideas you have there. My hope is that the AI/logic of the act of communicating would take this into account. Of course, this adds an additional layer to the puzzle as the mobile device has to be able to read this information from a network level, and then learn and adapt itself to the user's mode of using it. In a sense, you shouldn't ever have to switch your mode for anything - the mobile should be able to pick that up using its sensors and the context (which includes time of day, availabilty as noted via location and calendar, etc.).
0
0
This IDEA is fabulous and should be revisited and voted on.
0
0
|
Idea Stats
Idea Approvals
Team Members
Similar Ideas
Who Else is Viewing0 Members, 0 guests
Email Group |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||