Hacker Newsnew | past | comments | ask | show | jobs | submit | Dysiode's commentslogin

That's what I love about cottonTracks, even if it does lack a bit in the portability standpoint.


Or, even better, have a demo on the home screen, or at least a link to one.


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).


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.

Just my two (or more) cents.


I think the problem with offering both options is that you can't count on your customers to choose the right one, and they'll blame you when they choose the wrong one.

Customer (via SMS): hey, the whole internet on my phone crashes when i use feature x. wtf???

Customer Support Rep A: Hey, we'd be happy to help you with that. What platform/version/subscription do you have?

Customer (7.5 hours later): its the latest version, and i have a verizon. why can't you guys fix this???

CSR B: [lists some possible troubleshooting steps, asks customer to call]

Customer, the next day on Twitter and Facebook: [Company] has the worst support! They broke my phone, and they say they'll help you by text, but then when you ask them anything they just ignore your problem or tell you to call anyway. FUCK [COMPANY] AND DON'T BUY THEIR CRAP!!!


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.


This rings very true to me. It makes me wonder why most commercially supported software sold to end users doesn't have remotely activated remote administration built in, scary though that may sound.


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.


Are they actually ported? I've played Sonic games on iOS that were just emulators (awfully done emulators).


I have Final Fantasy 1 for my Nokia, and it's actually a port rather than an emulation. I haven't looked up the differences, but what I've found so far are: The interface supports tapping on characters rather than selecting them with the 'directional-pad' which appears on the map when walking around. There's at least one new area to explore. The magic system is more like later games, using MP. Graphics have been improved

I'm not sure how many of these are ports from the DS version, though. Possibly all of them.

Based on the screenshots of FF3 for Windows, it appears to be a port of the DS re-make rather than the Famicom original


I think they're mostly just ported. I've bought a few of the Square games on iOS and they were just the normal games with touch capabilities added on top of the old menus. No usability changes at all to accomodate modern touch patterns. There are many "click" needed to navigate some menus, which would just have been one touch or drag in a modern app. Scrolling was also laggy and glitchy.


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.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: