There's no reason not to do that on a mobile device, although minimizing the needed keyboarding is a plus there. Typing is just less efficient on small devices. Although the typing speed some people can achieve with two thumbs is fairly impressive.
And yes, some attention to the design and layout of the page to make it easier to use on a small device is useful as well. As I mentioned, it's not that hard to support a couple of versions of your web site, one optimized for desktops, one for mobile devices (obviously it's more work at the server end). The biggest challenge is identifying the class of device, you can either detect via code like that available at
formatting link
, or just have two sites (mywebsite.com and m.mywebsite.com is fairly standard), so some combination of the two plus a way for a user to decide which one they want.
But also consider that many mobile devices, even fairly small ones, do a fairly creditable job of dealing with "full sized" web sites.
As a general comment, I suspect that many of your users would *much* prefer to see a web site (or an app) rather than have to deal with an IVR system. *I* would certainly fall into that category. Of course there will be some people who prefer the IVR system (they may only have feature phones, for example), or may actually want to talk to a human (and supporting customer service agent from your central server would be possible too - really just an extension of the normal full function web site).
Have a registration procedure, just like everyone else (and don't you need to create an account for these people for login/security purposes anyway?). But this is providing a function you're not offering to SMS-command-senders or IVR users anyway! Notification when you're
*not* connected to the service. Not you *can't* do such a thing (the IVR system could phone the user when the house temperatures go out of limits), but you'll need some sort of registration procedure to support that anyway (house #17 is too cold, who do I call?). Plus users may want to specify more than one notification service. United, for example, notifies my both by email *and* text about flight status changes and whatnot. The emails are longer and more detailed, and include clickable links, graphics, etc., but are not nearly as convenient to see on my phone as a text.
Usually folks supporting that sort of thing generate a test message you have to respond to in some way as part of the registration process, mainly to ensure that you have the phone number or email address correct.
Which I why I keep suggesting that. I just mentioned that you *could* do an app with more sophisticated* capabilities if you wanted to. Such a thing would still communicate to your central server, but (obviously) depends on code running on the device.
*For example, an Android "widget" could continuously display some of the home system parameters in a small fixed window on the home screen
- stuff like temperature, the lock status of the doors, the position of the garage door, the latest alert, etc. It could either poll for status changes, or you could push those from the server. And if the user taps the widget, it launches the web site. Again, just a possibility.
I'm not being entirely fair in this discussion :< I am voicing the questions and needs of three different viewpoints in my comments without differentiating them in any (obvious) way.
First, there is the "information gathering" function of just trying to understand what the technology can do, its implementation(s) and limitations thereof.
Beyond that, there are two other voices poking at the technology, through you, to see how it fits *their* problem domains.
The first is trying to address the needs of this nonprofit I've mentioned, here. In that, several different types of users need to remotely interact with the system I'm designing. They will typically be issuing "requests" (for goods/services) and status queries (as to the nature of their outstanding requests!).
For privacy reasons, Tom shouldn't be able to see Joe's requests their status, etc. Nor should Tom be able to make requests/queries on behalf of Joe. Or, *forge* Joe's requests/queries. (lets call them "commands")
Commands can be initiated through a variety of mechanisms:
- in person (in which case authetication is done by possession of an "ID card" along with personal recognition)
- over the phone (in which case, the receptionist does whatever is required to assure him.herself that you are who you claim to be given the nature of the command you are attempting to make)
- via IVR (press or say '9' to be connected to the automated attendant)
- via email (I deliberately list this before SMS)
- via SMS
- WWW interface (We've touched on the authentication requirements of these last few)
"In person" is expensive. It ties up the limited staff at the organization as well as placing a large travel burden on the clients (it can easily take an hour to get across town in a *car* NOT during rush hour! Imagine traveling from ~Morton Grove to !Downers Grove yet staying *within* the city *after* school and getting back before bedtime!)
"Over the phone" is similarly expensive to the organization. Ties up staff who are effectively acting as transcriptionists. If this option is convenient for clientele, you can bet they'll use it (much to the chagrin of the organization -- how often do you press '0' when dealing with an IVR system?!)
"IVR" extends the benefits that the client obtained (i.e., not having to drive across town!) to the orgainzation as well (not having to "play secretary" for the client). It's chief benefit is that it works over *any* voice channel. It can effectively replace the "secretary" role that the phone contact requied.
"Email" gives IVR in SIMPLEX or HDX mode (if needed) over a *data* channel. But, requires access to an internet.
"SMS" (my understanding of it) would give the same sort of capabilities but over a cellular provider's data channel. It would require a featurephone (?) or better. (again, simplex/hdx)
"WWW" brings us back to an internet (even if it is a data channel hosted by a cellular carrier) with FDX mode.
Clients (HS/JHS students) *probably* have a phone. Though it may be a *subsidized* phone (like 250 voice minutes per month; no idea what sort of text capability -- I have that on my ToDo list for today). Given that most of these students are disadvantaged, expecting them to be carrying an iPhone with a great data plan is a joke: "You can afford the monthly service fee but can't afford *food*??" (that's not to say that this doesn't happen! :< )
This not only constrains what can be done via a "smart phone" but, also, how SMS and IVR would be implemented -- you can't waste two minutes navigating a bunch of menus each time you interact with the system!
This is why I thought texts might be more efficient: you *know* what you want to tell the system. So, *tell* it! (instead of "interacting" with it) Ditto email.
[Q: Do *received* texts count towards your "quota"/allotment? If so, how do you prevent Joe A**hole from sending you 200 texts each month (assuming he has "unlimited" plan)?]
A WWW interface requires a daa plan (?). And, a *friendly* web interface would be very lightweight -- so very little "data" moves across the link on each visit/interaction.
[An app could be even more miserly -- encoding entire "screens" in short messages: "Show the main menu; wait for a selection"]
Given these options, kids will probably migrate to the phone, IVR (if the phone is "discouraged" by policy) or WWW/email at a workstation (e.g., at their school).
Ah, but not all users are clients! E.g., school administrators and liasons may want to issue commands for the benefit of individual clients (students). They, of course, need a higher level of authorization -- less spoofable. And, they probably want things at *their* convenience (smart phone? talking to a real human?)
And me? I'm the laziest of them all! I want to invest in *one* interface that is "easily" portable to these different media. I don't want to have to design an email interface, SMS interface, WWW interface, IVR interface, etc. Rather, I'd like to have *an* interface with "affectors" that allow it to be mapped to different media. So, I can add features to the "interface" without having to modify all the "end user" manifestations of that interface.
The account implicitly exists -- they access it "in person" via a physical token (ID badge). I want to implement gateways into the same system from these other media.
I.e., instead of looking at your request statuses (statii? :> ) on a kiosk, you hear them spoken via IVR. Or, summarized in an email/text. Or displayed on a www page, etc.
[I'll skip describing the other app -- "brevity" Ha!]
I'm not seeing (for this app) "notifications" as asynchronous events. Rather, part of any:
-> "Do this" "Yes I did"
-> "OK, its done" authentication/confirmation scheme.
I could *add* such a feature -- that would allow notifications to be delivered in a client-specific manner (i.e., folks without SMS might receive a phone call; folks who don't want to squander minutes on a phone call might receive a letter in the mail; etc.)
Right now, I'm just trying to sort out how to get "commands"
*into* the system...
Understood.
The downside (for this app) is folks (clients) will probably only be accessing a WWW interface from a "workstation" (see above re: phone service limits).
It's most important for me to drive the interface from one point. Then, "adapt" it (with these "affectors") to different media interfaces. That way, any changes are "instantly" propagated through user land.
Think of how you would query an FTP service to see which commands it supports. Or, send a query to a list server to see *its* lexicon. The same sort of thing can happen without requiring "apps" to be updated.
For most *common* requests, you wouldn't have to think about how to issue them. "Is my check ready?" would be something you could type in your sleep! :> ( :< )
Well a "featurephone" is pretty much the bottom rung of the ladder as far as phones go. Pretty much any mobile phone can text (a tiny number of exceptions exist). But even featurephones common offer browsers, facebook and twitter access (but few, if any apps).
The big problem with these two options (email and SMS) is that they're hugely clumsy. You're requiring the user to send a command string, which your host will acknowledge. Yes there are people doing that (for *very* simple applications), but everyone is going to hate that UI.
Well, I'm not sure about the audience you're targeting, but phones with basic data plans can be fairly inexpensive, especially if you avoid the "big" providers. Prepaid phones have an every lower entry cost (although actual services are metered in a fairly expensive manner - if you don't use that much, it can be a good deal).
I understand your thought, but just how much training (and typing skill) are you expecting of your users. OTOH, accepting highly free form command entry is a huge undertaking.
Yes. As do both inbound and outbound phone calls.
Yes, although that can be a very low minimum on a prepay or pay-as-you-go plan (although the cost per byte on those ends up being pretty high).
Of course. Your server provides a core set of services, and you have code that maps the particular device to those services.
Of course that doesn't actually protect against CID spoofing. The originator of the spoofed message just needs to send "Yes I did" 45 seconds after the original command message with the same spoofed CID. Requiring a specific response (say including a code number from the "did you just..." message fixes that, but your UI is heading rapidly downhill...
Yeah, I just think that's a hugely unusable interface for most users.
I'm not saying that you shouldn't do an SMS based UI, but I think you're underestimating the availability of a browser on the one side, and just how ugly the SMS based UI is going to be on the other.
The beginning of this year had *global* sales of smartphones (in units) exceed those of feature phones. It's rather better in the more developed world. Plus many feature phones now have browsers, etc.
In any event, doing a "lite" web interface is going to be one of your simplest chores, especially since you'll be able to rip most of the code from the "full" web interface.
I don't think any of the programs available to these students go beyond voice+text (I think even text is if-fy). The so-called "Obama phone" (started by that stalwart of liberalism, Ronald Reagan, in the 80's and extended to wireless carriers by yet another liberal, George Bush):
[Links provided to make it easier for those who want to rant about "yet another lefty program" to get a start on their fact checking before ranting, here]
Gee, I guess they *do* care for the "47%" after all! :>
From what I can gather, all you get is a "featurephone". And, you
*might* get a text messaging quota (from some providers).
Visiting some of the web sites of those providers seems to turn up "plain vanilla" phones:
I don't use a phone -- let alone a *cell* phone -- but it seems like 250 minutes/texts is *nothing* given the usage I see from folks around me (?)
Well, what other alternatives (see my previous post) do they have?
- They can tie up a real human on the phone making verbal inquiries
- They can call and deal with "press 9 for..."
- They can visit a WWW page from a workstation in their school/library
The first option scales poorly -- more clients means more people competing for "phone time" with a human. How many minutes will it take (on your quota restricted phone) to get the information you need? What if you are put on *hold* during your call (because some
*other* person is calling with a similar request)? What if you want to call after business hours?
The second option I can probably trim to under two minutes -- maybe even under *1* minute for folks "familiar with the interface" (so they don't have to wait to hear all the voice prompts -- just start pushing buttons as soon as the call is answered).
Each of these two leaves "data entry" (beyond menu selections) to be a manual transcription exercise -- the UI can *record* what is spoken ("What is the nature of the emergency to justify your request for $200?") but someone has to transcribe that into the formal request.
Third option means they have to be somewhere that has a computer and internet connection available for their use. So, its more convenient (to The System) wrt getting data directly into the system without transcriptionists, but, less convenient to the user (who now has to get his body to an "access point").
SMS/email may be lousy interfaces. As is a wheelchair a lousy way to get around! (unless, of course, you have no legs -- in which case it is an "enabling technology" :-/ )
I've got to design within the constraints set before me. Unlike Kirk, I can't "reprogram the simulation" to come up with a winning strategy!
See above. Remember, these are kids. Far more likely to *want* to use a phone than you or I, perhaps.
You don't have o support a natural language interface. Just some number of verbs and nouns.
E.g., when you interact with an automated mailing list, you don't send *prose* to the automaton running the service. You just say "subscribe" and, optionally, the name of a list.
So, for example, a message could be:
"meEtINg I want to discuss problems with liViNNg arranjments"
If the system knows (authentication, sim cards, etc.) who the request is from, this is effectively:
From: Via: SMS service Date: Time: To: Reason: I want to discuss problems with liViNNg arranjments
Ah. So, each half of a round trip bears a significant cost. As such, I want to find ways to rely on any "authentication" being present in the initial request. Either something that can't be spoofed (SIM?) *or* requiring the user to submit a shared secret with each request:
"meEtINg I want to discuss problems with liViNNg arranjments"
And, they would need data capable phones. I.e., can they be in the aforementioned plan(s) and *replace* their "issued phone" with a smart phone (procured by some other means)?
There's no "reply" ability with SMS like email? I.e., "To confirm your subscription request, please reply to this message while leaving the headers intact..."
But they (and I) don't have much choice. As I told Nico in another thread -- the option to use "game consoles" only applies if you *have* game consoles to *give* to them!
I suspect the organization could probably start a donation drive to collect "used" (and new!) smart phones. But, who is going to foot the bill for the *service* that goes with them?
Why do people send texts instead of *talking*? It's got to be more tedious to type out amessage than it would be to simply *speak* it! Especially if it becomes part of a *conversation*!
From this, it seems the most effective solution is a regular web interface and just tell them they have to find an internet-connected "PC" from which to issue it. This just requires some authentication (password/challenge-response) and lets them say *everything* they need to say -- in a form that I can just slurp into a database.
Given this, there's no advantage to an email-based interface.
And, just disallow phone access entirely. Voice menus will only be effective when there is nothing "variable" (besides numerics) that they will have to enter. (Transcription would be even more expensive than hiring another person to answer phones!)
Hmmm... I'll have to stew on this. It seems like setting a pretty high bar for folks to interact with a system that is supposed to be *helping* them deal with the challenges they face.
I've been "building" laptops for distribution (to this same population). Obviously, went on-line to see what I could download for drivers, etc. "Ah, rather than download all these individual drivers, I can request a 'restore disc', by mail, that has the added benefit of saving me the trouble of *burning* one to distribute with each laptop!" Special web page dedicated *just* to this!
Type in "service tag". "Out of warranty". Well, no surprise, there! They have, after all, been *donated* so unlikely they are new enough to still be *in* warranty!
"Hmmm... for out of warranty support, call..." OK, toll free. I can spend their dime!
"WTF? Someone trying to sell me a cruise?? Did I misdial? Try again..."
Ah, OK. Web page is apparently out of date and no one has removed the toll free number SERVED UP BY THEIR DBMS APP that is obviously no longer "owned" by said company!
OK, let's try main support number and see where we go from there...
Eventually, talk with a pleasant gentleman regarding my needs. "I've got six of these (identical) systems to build...".
Apparently, he needs service tags from *each* of them. "Can't I just use *one* set of disks to install for all the machines? Each has a unique license CoA attached to the case..." Unfortunately, I only brought one of this model home with me so only know the service tag for *it*.
No. OK, can't fight city hall...
Next day, CD's arrive. Great! Meanwhile, I get the service tags for the other 5 units.
Technician calls to confirm I received the first set of discs. And, I tell him I now have the service tags for the remaining five units.
"Great! What are they?"
Read 5 seven character tags to him. Wait for him to repeat them back to me. Assure him my name hasn't changed in the past 48 hours. Nor has my shipping address, etc. I.e., he has all of this on the
*original* order from the previous day IN FRONT OF HIM.
One hour and six minutes later, these five IDENTICAL requests have been processed. Assume a minute or two on "pleasantries", that's still 12-13 minutes per request. And, all of the information was already there in front of him!
And this is a Fortune 100 *technology* company??
Yes, obviously outsourced, etc. My point is just how much time dealing with a "live human" can take.
"Hi this is Tommy. I wanted to see if my bus pass is ready." "Hi Tommy, what's your ID number so I can check" "Wait, I've got the card here somewhere... no, I can't find it. Can't you just look it up. 'Tommy Smith'. I go to Great High School." "Hmmm... OK, Tommy. I think I have your record here. But, I can't tell you anything until you give me your password" "12504 or, maybe its 12405?" "Hmmm.... OK. Apparently, your request hasn't been approved yet." "But why not? I need it to get to school Monday." "Could youhold on a second? I've got another call coming in..." [musak] "OK, I'm back. Let's see... it says here you just *requested* it yesterday. It's likely that your advisor hasn't had a chance to review it yet." "But, when will that happen?" "Let's see... Bob is your advisor and he's on another call right now. Can I have him call you back?" "No, I'll have to try calling him back. What time do you think would be a good time?" "Gee, I don't know. You'll just have to try and hope he's available. Do you want to *hold* to see if he gets off the phone soon?"
Repeat this for ~1000 clients every month. Even *one* one minute transaction per client per month represents 2 man days of labor... about 10% of an employee's time. And, these are just "status updates", no real "data entry" involved.
Reagan would likely have no chance at all in any recent Republican primary.
Certainly the texting habit of many teens is mindboggling. A few years ago Nielsen published a report that the average female teen (13-17) sent about 4000 texts per month, their male counterparts lagged at "only" 2500 or so. And even that is starting to decline, as more of the social activity is moving to social networking.
I feel for you. You've got a difficult set of requirements. You're going to probably end up putting a fair bit of work into some of these UIs, and end up with pretty limited use.
You seem to be far more phone resistant than I am. OTOH, the least thing I actually use my phone for is phone calls.
You can reply, of course, but there is no prior message copied, no headers, it just sends the message back to the number it appears to have come from. The receiving phone will usually sort the conversations into group based on the other phone number. Remember, you've got 160 characters here. If I be so bold as to suggest that before trying to design a UI using SMS, you ought to do a bit of texting yourself first.
Phone calls are massively intrusive to the receiver. In fact, many people consider unscheduled phone calls not concerning near emergency situations to be flatly rude. And that's not limited to teens. So much so that an unscheduled phone call from a friend leads to a bit of an "oh crap, what's happened?" when you see their name pop up with the ring.
Not only have a quarter or more of the landlines in the US gone away, phone minutes used on cell phones is also showing a significant decline (both in number of calls and duration). Between 2008 and 2010 the number of voice minutes used by 18-35 year-olds, dropped by a quarter. The trend has not been slowing.
Conversations with elderly, and non-texting, parents excluded, of course.
Phone calls are also fairly solidly two-party (yes, you can do conference calls, but those almost *have* to be scheduled), while texts can be a group thing if desired.
And even when you're having a conversation, it's not constrained to the duration of the phone call.
Obviously business situations, customer support, and the like are different. And even business communication often tends to be non-phone (usually email rather than text, but same principle), and phone calls are often scheduled.
I don't want to (completely) discourage you from pursuing an unusual alternative UI, and the architecture you're describing should let you graft on additional/experimental UIs pretty much at whim. OTOH, that no one else is doing this is sometime an indicator that it doesn't work well. OTTH, many of those decisions are made assuming people who might be buying something, so would specifically exclude a motivation to accommodate many of your potential users.
Doing this via SMS is just going to be very limited, and more than a bit ugly - still, some simple stuff may be possible - notifications are certainly a good use ("Your appointment at Xyz is for 2:30pm, Tuesday", and appointment *reminders*), and you might get some simple interactions. One possibility is scheduling a phone call with a customer service agent - you might just have a human receive those texts, schedule the call, and send back a confirmation with a time, etc.
A number of other countries are, or are moving towards, making sure that the poor have a reasonable level of participation in the digital world, not least with subsidized smartphones and plans. While not all services can be provided via a web site, many can, or support for those services can, and delivering those services that way can be very cost effective. Subsidizing a smartphone to enable that, might well be a net budget positive, while giving the users access to the digital world.
Here, of course, we prefer to further punish people for being poor.
Not that I'm challenging your numbers... but I find that hard to believe! 4000/month is ~130/day? Assume they are "awake" for 16 hours... that's 8/hour or one every 7 minutes?? And, "during school hours", presumably, they *aren't* texting (is this a flawed assumption on my part?). So, the "peak" texting frequency has to be even more than that!
[Yikes, no wonder the push to end texting while driving!]
I obviously need to rethink all this. There's got to be a "twist" that will make it all work (he said, hopefully). I need to find a medium that is inexpensive, low bandwidth (i.e., voice channel in the legacy sense)
I despise phones. In my warped view of the world, phones exist for the convenience of the *caller*. *You* want to know something
*from* me, you don't hesitate to *bother* me by *calling* me! Doesn't matter if I happen to be engaged in some other activity (or, *asleep*).
Of course, it's impolite for me to return your call at 2:57AM... :>
Email is The Great Equalizer. Send it when you want; read it when you want. *And*, you've got an undisputed record of BOTH sides of the conversation!
That's the purpose of asking these questions! :> Getting a phone for a month and sending "artificial" texts doesn't seem like its going to teach me anything more than how to push buttons. I'd have to have a genuine *need* (motivation) to truly understand what's involved and where it falls down.
But the "chirp" of an incoming text *isn't* intrusive? Not being a phone user, I am keenly aware of how many times people drag their phones out of their pocket WHILE ENGAGED IN A CONVERSATION just to see who the text is from -- "Hold on, let me just answer this..." (Why? It's going to chirp again in 30 seconds with the *next* sentence in the conversation... just make the damn call and be done with it!)
Ah!
Hmmm... but, a "group" (i.e., "Cc") text still gets charged to the sender as *one* message? But, each recipient sees it as an incoming text as well (i.e., if 7 people in the group -- plus sender -- the phone company charges 8 units for this transaction -- spread among the 8 participants?)
Again, the downside is the cost of the confirmation. You don't want to send it "unsolicited" if the recipient has only a few in his monthly quota.
OTOH, if he has to send a text in order to *get* the confirmation, then the cost of that transaction is now *two* messages.
I'm not smart enough to solve those sorts of problems. Far easier for me to find solutions within a given set of constraints (than to suggest "moving the goalposts").
Of course! It's clearly their fault! As is the color of their skin, sex organs they possess, their religious perversions^H^H persuasions, etc. :<
(sigh) Thanks for all your time on this, Robert. It's apparently not going to be as "easy" as I had thought -- too many changes to the cost model than I had anticipated. I now have a better understanding of why the phone rings off the hook when I'm there and the amount of "mindless labor" that's being wasted on a trivial activity. (if it was easy, someone would have already done it!)
Of course I managed to turn "sends or receives" into "sent" in the above, but...
The original study:
formatting link
A follow-up talking about data and phone usage as well:
formatting link
I'm pretty sure I agreed with that already... ;-)
Think of SMS as email-lite, not a direct equivalent of a phone call.
No the chirp is not intrusive*. It's perfectly ignorable, unlike a phone call, which you basically miss, unless you answer it. Now the
20 second long repeated ring of an incoming phone call is *really* annoying.
What you're experiencing is *rudeness*. Checking your texts for no good reason during a conversation with someone is just rude. Although even then, you can scan an incoming text in a couple of seconds (it is rather limited in length, after all), unlike a phone call.
Again, email is similar - your PC (probably) beeps at you in some fashion when an email arrives. If you were talking to someone in your office when that beep happened, it would generally be rude to stop the conversation and read your email.
And just like with email (and incoming phone calls), you can set the announcement tone differently for different senders, allowing you to filter out many of the messages at time when you want to be paying attention to something.
*It could be quite annoying, since you can generally set the announcement tone to any recording** you want. You can get pretty obnoxious. OTOH, since *you* have to listen to it all day, the novelty of an intrusive "chime" wears off quickly.
**When I got my mom a newer cell phone a number of years ago, news about ringtone was all the rage. She asked me what ringtones were, so I showed her. I set the ringtone for her phone to the audio from the famous scene "When Harry Met Sally". For some reason she made me change it back to an ordinary ring...
A common way this would be done is via a tweet - so one message to Twitter, and one to each user following that channel. Most users with a smartphone (or better feature phones) will use an app instead, not only a better UI, but cheaper too (text messages are astonishingly expensive per-byte*, and using an app instead moves that to your data plan).
*Typically for texts above what your plan covers you're looking at
10-20 cents for each (up to) 160 byte text. Even pay-as-you-go data plans are usually only a couple of dollars per megabyte (although most of them allow you to buy bigger blocks in advance at considerable discounts). "Real" data plans are ~$10/GB. You can fit a lot of texts in a megabyte.
And a phone call isn't free either. But a few quick texts are not usually an issue. In any event the user would register for that - if they didn't want to receive texts, they'd not register for them.
While we're on the issue of costs - cells phones, and many VoIP phones, charge minute for both incoming and outgoing calls. This is one reason why toll-free numbers are starting to die as well - the long distance call from your cell or VoIP phone is free anyway*, but you pay for the minutes no matter who you're calling, even if it's a toll-free number.
Applications like Skype further turn phone calls into cheaper data usage.
*IOW, the owner of the toll-free line is paying extra for each received call in order to save the caller *nothing*.
OTOH, 600 minutes a month *talking* doesn't sound unusual. When I was a kid, I can recall my sister yacking for an hour or more each *night*! What the hell can you *say* in all that time -- to people you just saw a few hours earlier (school) and will see again a dozen hours hence!?
But, this makes clear that "250 minutes" (or texts) probably feels like living on bread and water to these kids! :<
Yes, that's why I originally presented it in the context of "(traditional) email" -- "mobile email"
I know my deaf friends think it is the greatest thing going!
*I* find it annoying when talking to people and their "pockets" are constantly moaning. Turn the damn thing *off*! Are you that starved for "human contact" that you obsess over a *machine*?
Set phone to go to voice mail. We don't answer the phone, here. A few times a day, we glance over to see if the little light is blinking. If so, we *probably* go and listen to the messages we "missed" and decide which ones to return. It's great cuz folks
*know* they can just leave a message without having to engage us in a lengthy, "So, how are the kids?" set of pleasantries...
(sigh) I guess my mind is just not wired for that. I *really* dislike interruptions. SWMBO tends to listen to the radio when home. *If* they just played music (even if it was music that I didn't like!), it would be tolerable. But, to hear the DJ, "station identification messages", etc. interjected is "jarring". I much prefer putting on some "album" and letting things run for hours without having a "voice" draw my attention away.
I understand what you're saying. In my case, no "notifications". If I'm sending a message to someone and something comes in while doing so, then I will see it. Otherwise, "next time I go online" (I work at a different machine than this one -- which has inet access)
Understood. Some folks have insane tones like "Thus Spake Zaruthstra" (which always seems "rude" to interrupt prematurely!) Makes you want to try something like "Alice's Restaurant" (long cut) to see how *determined* folks are to actually get through to you! :>
Yes. And the "fake ringers" on new "electronic phones" sound so cheesy...
So, even more "indirection". Cripes, like using ! notation to route email!!
Yikes! OTOH, the phone plan I mentioned previously reimburses the carriers ~$10/month for 250 minutes (and some *add* 250 texts to that). So, the carriers could easily sell them for 4c/ea.
Understood. Years ago, things were much simpler: dial 1 for long distance, everything else is free! :>
I suspect they would want a "callback" on some inquiries but not a "routine notification policy". I.e., more complications in a UI...
Understood. So, those of us with land-lines will eventually be paying 2c/minute for those calls...
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.