This is one of the most grounded and realistic responses at the moment, and I would like to add a bit from my experiences with anxiety and depression.
While my symptoms weren't as severe when I went to see a psychiatrist he stated future sessions would be less about therapy and more focused on how the medication was working. This may have been poor luck on my part but I instead found a PhD level Psychologist instead because their focus is on perspective and providing you with mental tools you can use over and over again.
That said, I'm not discouraging medication, simply ask your psychiatrist about how much therapy you can expect in addition to the medication, and considered also using a psychologist to help provide mental tools.
There are some interesting hurdles, and you've done a great job of thinking of a few of them! I can see three likely async solutions: SMS style message based (explicitly not real time), real-time message based, or real-time chat.
SMS Style Messaging: In my customer-facing experience with the concept I don't think SMS is suited to the challenge. Instead a full fledged chat application would need to be used. As far as queuing goes, related to this and my experience with Simple most of my interactions a) aren't real-time and that expectation is set when I create a message, and b) if they go on for a period of time they're handled by different CSRs. I've never had a poor experience because of that.
> With a voice call, the representative is on the line with you until your problem is resolved.
Additionally, related to this, there are a lot of times where that's not the case, or there's research to be done and if I were allowed I could do that research and come back with a response. That's discouraged/forbidden in call centers because there's the assumption you won't perform without pressure but that's almost certainly a staffing issue (or if there are too many basic/uninteresting research requests then it may be a systemic problem).
Real-Time Messaging: If we're looking for a more real-time message based solution (i.e. not chat), a single CSR could handle a few requests, but if they get a particularly detailed one there could be an expiration that hands it off to another rep, but that could get messy fast, even with a "So-and-So is busy at the moment, my name is..." (though with more elegant verbage).
Real-Time Chat: As I do everything in my power to avoid calling people, I will use chat if available as an alternative. Now, I can't say I've asked every person I've spoken to, but I know a couple of cases where I can confirm I was their sole interaction. It took a bit longer, but I was doing other stuff while I waited and I had the expectation when I started the interaction.
tl;dr Set expectations of delayed responses to messaging based support, don't bother with real-time messaging as it doesn't make logistic sense, and treat all real-time support the same (one active interaction).
That's absolutely valid, CR exists because customers don't know what to do next. That said, there's a lot that could be done to mitigate that.
- High phone support visibility on how-to pages: Don't link to chat if it's not going to an ideal experience
- Focus on customer facing how-to resources: I'm confident every minute spent making the thorny aspects of phones (e.g. moving photos from internal storage) rock-solid is worth no less than an hour of CSR time.
- Proactively making recommendations on more ideal support scenarios if applicable: "Hey, before we get started, this part can be tricky and I'd love to walk you through it, it'll only take a few minutes and I can schedule a time to call you if you're busy right now. <details of next steps>."
- Perhaps most importantly (I just noticed from your interaction) CSR A should handle (and be given the freedom to handle) the problem from start to finish OR it should be made -very- easy for CSR B to pick up where it was left off (either a great CRM or an honest "I've got a family to go home to, I'm going to hand you off to So-and-So or I'll be back and available at"). That said, Simple lacks consistent CSR interaction but I haven't encountered a problem with the hand-off, most of the time I never notice.
When I was a CSR 99% of the time the customer wasn't my enemy, it was my coworkers (or my CRM).
That said, I don't believe SMS literally is a reasonable form of support and should never be marketed that way, but chat, even in-app chat could substitute. Additionally, providing these methods gives people a chance to ask questions and get resolutions that may be nagging them but not enough to call someone, it also opens up lines of communication to people like myself who get anxious thinking about calling people.
I'm not sure how this is necessarily much different than phone communication with the notable caveat that text is quicker to parse. It's already inadvisable to give that information over the phone as a landline can be tapped and there's plenty of proof of concepts of tapping wireless networks.
At least with an app you have the option of adding in security layers. SSL for one, Simple uses a PIN on their app, Art.com will process a transaction in chat but direct you to their website to submit payment information, and on top of all this you have the added benefit of easily documented interaction. -You- can reference your own interaction without the near impossibility of having a call recording audited (as a call center CSR and supervisor I've seen this happen no more than six times).
In fact, in one interaction with Art.com I sent an email to an agent with photos of some damage to the piece they shipped me in my initial email which resulted in a resolution in the response.
Another case with GIGABYTE I was able to send photographic description of my issue due to a consistent (likely language barrier related) misunderstanding about what was meant by "a missing pin." which immediately clarified the conversation and we were able to move forward.
tl;dr the variety of "offline" security measures available and the convenience gained with "offline" support makes that minefield significantly less dangerous in my experience, especially considering the dangers already present in phone based support.
I can see there being a happy medium here as no all support requests are task oriented. Either a) asynchronous support for support inquiries like "When will product x be in stock?" or "What does policy y mean to me?" where as "How do I setup email on my phone?" could be handle synchronously. or b) begin asynchronously and move to synchronous communication as needed.
At the very least both options should be offered. I almost exclusively use text-based communication unless it's a time-restricted request. This works well for Simple (the bank) where I tend to have a lot of financial questions that I don't need answered -right now- so I shoot off a quick message and follow up if needed; however I've had a couple of situations that required immediate answers and response and those times I absolutely picked up the phone.
Having worked in tech support for two major telecomm companies though, I'm convinced it's most commonly a problem of formatting. The discrepancy between instruction and reality is what throws non-technical people off. Given accurate instructions your grandpa could figure it out at least 75% of the time. One of the companies placed extreme emphasis on their resources with the reasoning "They'll figure it out." and according to them and their metrics they seemed to think most people did figure it out by braille if you will.
A touch interface, for one. Emulates are find and all but I find their inaccuracy frustrating more often than not. Further, it's not just a 20 year old game on an emulator. Somebody has to port it, make graphics (for what they are worth), probably localize it. Sure it's not necessarily as hard as making a game from scratch (though that could be debated), but that doesn't mean the costs aren't similar.
I'm largely a fan of the idea I've felt the burn of the "I paid full price for this because I appreciate your work but now it's 33% off?" moment (Borderlands anyone?). I want to see that abolished. Because I've seen a lot of negative feedback of the argument, I want to offer an addition to it.
As an example, I had my eye on Kentucky Route Zero since I saw it in IGF and I fit the example user "It'll go on sale. I'll wait" But after a year it only went on sale for 50% (crazy, I know) and that happened a couple times. At that point, I knew it wasn't going to go to 66% or 75% any time soon so I picked it up. I can see a happy medium with sales where you make it clear that you won't go on sale for a certain period of time and/or for a specific discount. You don't necessarily have to verbalize that either. I don't follow any KRZ news but it was clear that that price point was not going to change quickly. This way you still get the press about sales (I saw a lot of KRZ at 33% and 50%) without having to screw fans over.
I'm sure there are a few ways of strategizing it that would require some experimentation (e.g. a bit before a steam sale, have another 10% type discount like might be seen on launch week but make it clear that it's not going to go below that). There are also more mediums for sales with the Humble Store now you see a lot of games with shallower discounts.
I will say I don't think this model works as a long term plan however. I like the idea of starting low for pre-orders and then increasing the price over time, but I don't think it would work as expected over a two week period. With Minecraft there was the expectation of more content over a period of a year or so between increases. It may still be viable but that may be a case for early access. Make it clear there that the price will increase when it's finished.
I hate seeing what appears like developers feel like they have to sell out on their baby, and I hope something like this can work.
I felt the same about the thumbnails. Then I checked out the new articles and could easily pick out the spam (Indian Party Wear Sarees in this case). I don't think it's so useful for the top articles since most are primarily textual but it brings out an interesting use case for unfiltered content.
I'm wholly relieved that someone else thinks this way too ( still aware of the fact that most thoughts aren't unique). I never came to the conclusion of metamorphosis, however.
Just felt a need to express my experience of camaraderie on the subject.
One could argue that applies to sci-fi as a whole, but some how Vingie's vision of omnipresent dust motes seems more likely (certainly given several hundreds years of cyclical progress, as in the story) than teleporters or even flying cars. Certainly the conditions in the novel were extremely conducive to that type of a network but such a ubiquitous, space filling network could be useful in plenty of other situations (rescue operations or something as simple as adding a puff of motes to a high traffic area to bolster a network for example). Is it likely? Probably not. Certainly not without wireless power, but it's probably more likely than flying cars as our primary mode of transportation.
For a more near future example Vinge presents the network in Rainbows End, especially given the work that's been done with Wifi meshes. Granted, I haven't heard any news about the idea lately, but as I recall, Google has one in Mountain View delivering free wifi to everyone in the area.
Now all they need to do is make the settings page match the rest of the site. Notably putting the Save button at the top of the page after making everyone get used to not having to scroll around to find the Send button.
It's a bit more complicated and requires you to get familiar with Qt's paradigms for things like resource management (I'm still struggling with how to access files outside a qrc), but it offers infinitely more flexibility by exposing the entirety of Qt (and C++) to you as needed.
For example, I wanted to write a frameless app with edge snapping. The two problems I ran across were:
- First, when expanding a window the mouse would leave the web widget and so Titanium would stop sending mouse events (as it should). To fix that I had to wrap my content and center it in a larger transparent <body> and then account for that in the movement code. Ugly, but do able.
- And then, edge snapping on the other hand is impossible. Titanium doesn't handle multiple monitors very well. In-order to get the dimensions of a desktop you've dragged into you have to drop it first and even then it's relative to the upper left corner of the primary display.
I realize these are very specific issues but they're trivial in Qt (I handle resizing and dragging in Qt so mouse position is no longer an issue, and QDesktop is extremely straightforward).
Furthermore, not every library is available in Javascript so it can be useful to fall back to C++. I'm still using mustache.js for templating but I won't be using Strophe.js for my jabber library, I can instead use quicker C++ power library (I'd like to use libpurple but that's a whole other mess itself).
I'd been familiar with the concept of verbs and nouns in vim but this really simplifies it all. I wish there was a more comprehensive list of everything in a readable format. Man pages just don't do it for me :(
From the document he links to it seems more like a fancy password manager that handles session cookies too with the idea of standardizing account management. Not necessarily a lofty vision but certainly something helpful and interesting (albeit seemingly dead now).
Teehee. Sorting by size sorts the string size rather than the true size. At first this leads to logical results, like 0.9GB being at the top of the results, and then you realize that 53mb file is right next to that 53.6kb file. Wait a second~
> Also when it comes to deciding if I want to share my public folder it would be nice if you could list what's in my public folder for me. I had to go check.
Agreed. It's shame Dropbox doesn't let you see what files you have in your Public folder more easily. It would be great if they could some how directly link it to a folder on your computer so you could quickly and easily manage those files.