Dysiode

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

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.

Just my two (or more) cents.

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.

See also: Vinge's Rainbows End for a near future example of ubiquitous networking (amongst other likely visions).

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.

As a consumer I personally prefer Amazon Payments. They already have my information and their checkout is familiar.

I can't say if they support international payments though (but they're a good "for US customers" option!)

I've had more luck with the QtWebKit Bridge: http://doc.qt.nokia.com/4.7-snapshot/qtwebkit-bridge.html than other options (primarily Titanium).

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

See Also:

There's a few decent Dev Days videos about it: http://developer.qt.nokia.com/videos#c-87

For completeness the one I've watch primarily is: http://developer.qt.nokia.com/videos/watch/hybrid_developmen...

And also there's a growing number of usable examples like http://doc.qt.nokia.com/4.7-snapshot/webkit-imageanalyzer.ht...

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 :(

Mozilla was working on a solution to this some time ago (back when Aza was still with Mozilla, early 2010 is the latest date in the linked design doc): http://www.azarask.in/blog/post/identity-in-the-browser-fire...

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.

Ah well, such is the state of the art I guess.

I like the idea so I'd like to share my thought processes as I used it.

Firstly, I had a basic idea of what it probably was having heard about the hack involving file hashes a while back.

While it gets permissions for my entire Dropbox I was aware it only interacted with my Public folder. That's fine.

After signing up it wasn't obvious what to do next, even with the random link. I searched for a file that's in a folder with no luck. My first random file is one of my own. through that trial and error I figured out it only interacts with the top-level folder.

Personally, I organize my public folder. In fact, I have a "persistent" folder that I use to link to, to imply the links are largely non-transient. I'd love to be able to index folders of my choosing.

If you redirected to a page to control that it would be immediately obvious what's shared and what's not.

EDIT: As an aside, I found some pretty neat files I'd forgotten about!

I'm actually surprised no one has mentioned Rainbows End by Vernor Vinge yet. He actually presents a vision of a very natural, expressive near future UI.

While he doesn't go into technical details about everything, he does describe interacting with "Ubiquity" through small gestures throughout the body, whether small shrugs or interacting with hands. Further, he touches on the issues surrounding flat interfaces and even the virtual 3D interfaces.

And that's just the UI side of the novel.

3: Chrome has the benefit of showing where in the page the results are inside the scroll bar. Dark-magics I say.

While Opera is arguably ahead of the curve in many areas I've always felt they lack the polish everyone else brings. Be it Safari's glossy SpeedDial or Chromes fancy tear-away tabs Opera has a great idea and then consistently falls short of the mark.

Worse the areas they didn't pioneer they still fall short. For example I go really excited about some of the parts of their extension API... until I read Chrome's API which is significantly more fleshed out.

I still can't tear myself away from Opera though. I just can't get used to the extension-based replacements for much of the native functionality, be it mouse gestures, the RSS reader, notes (oh gosh. notes.). It would be nice if, as David points out in his article, they focused more on polish than on new features. At the moment Opera feels a lot like "old" Google with a whole bunch of creative, yet half-baked, ideas.

A good reminder that sometimes there's wonderful things hidden in the unknown. I'm a IT newb, but I wonder if there's a sane way for backbone providers to communicate with startups to achieve that vision he presents at the end.

I don't seen the downside to verifying your account on a new device before being able to use it. If you have access to the appstore then you have access to Gmail and one simple email to say "Yeah, go ahead and let my friend's iPad buy this app on my account for 24 hours/7days/forever" is all it takes to prevent this sort of thing.

> We don't implement such paranoid measures either in other web-services or in real live, so I find it rather overblown to demand Apple does this.

Google Two-Factor Authentication, Facebook emails you when someone logs on using an unknown computer, Steam does the same, and I'm sure there are more examples.

It's only paranoia until something happens.

> This allows the creator to benefit in the case they can't personally exploit their work.

I wanted to be succinct for the title, but I'm more getting at why people other than the creator can sell a patent. Selling is still beneficial to the owner, however, if the company sells it after that then how's the benefiting the owner?

> What if the patent is a joint creation, or created while working for a company, i.e. the company owns it?

This is more of a side note to me, although, it looks like patents expire after 20 years. At least that's a number I've seen cited a couple places since posting the question.

With that said, maybe the pharmaceutical process is something worth looking into? I know the timer starts on their patents as soon as they submit it which long before they can ever produce it, but the point is that they're able to pay for all the research and trials involved in making the drug. Maybe there's some analogy for other applications (e.g. software patents)?

> Because there'd be a financial incentive to kill patent holders?

To be fair, a) people don't kill copyright holders before Disney got a hold of the legislation (or did they?) and b) I imagine the legal ramifications would outweigh, at least largely in part, the benefits of assassination.

"But what exactly does Google need to defend against, if not actual patents Android actually violates?"

I may be naive but I simply don't understand the concept of transferring the ownership of a patent. If Google buys a patent related to Android then HOORAY! They can use that idea in Android. If Microsoft buys that patent related to Android then HOORAY! Microsoft gets to sue Google.

It seems to me that "violations" are simply "didn't pay enough monies." Why is buying a patent your product violates a bad thing?

and, on a semi-unrelated note, why are patents transferable at all? Shouldn't they only benefit the person who created it? what claim does some arbitrary company dozens of sales down the line have to that patent?

I find it interesting that hackers of all people are so polarized about this article. I wonder if working in an industry with such a high customer turn-over rate where you either make it big or try something else has desensitized us to the fact the masses of people paying us $0.99 for our apps are still people.

Especially those of us in jobs with absolutely no customer service aspect whatsoever. I wonder if it would help to require everyone in a company to respond to a couple emails a week would help them feel more attached to the people actually using the product (In a way, Opera does this with their Desktop Team blog by having different people write a blurb before the change log).