If you'd asked me...
If you had asked me five years ago whether I thought I would be any of the following:
- in Taiwan
- working remotely for clients in the U.S.
- actively communicating with people in all areas of the U.S. and Taiwan in real-time
- sharing dynamically updated data, documents, resources, mixes, remixes and images with people all over the world
I would have said "who? What? WHY?"
So here I am, glamorously using Google, Skype, Audioscrobbler, SoundCloud, Twitter, Facebook, LinkedIn, the gamut of social and business communication applications that are based on servers all over the world (but mostly the U.S.) and therefore able to maintain connections with so many people, in so many ways.
Glamorous? Yes, of course I exaggerate. Its not glamorous to type everything you want, but having shortcuts on my desktop to everything would make my desktop unusable. I quick search everything, typing keywords and shorthand notes that are in titles and filenames. As a result I get things done ridiculously fast, and the only limit is the amount of memory on my system (which I need to upgrade, badly.)
The downside of global communication is the big red "OPEN 24 HOURS" sign attached to my head. Thankfully my phone doesn't ring at 12 noon U.S. time and 1am my time, and my business partner and I are able to maintain good relations at "reasonable" hours for the both of us. Add to that extensive logging of conversations, we're not trying to remember "what did he say last night when I was falling asleep on the keyboard?"
However, the client-side of things takes a toll, everything's expected to move faster, easier, as it SHOULD, but as things move more quickly, the quirks of "speed" become evident.
Yes, its insidiously fast to type the first four letters of something and have it open in 0-4 keystrokes afterwards. Yes its great to be able to receive and reply in less than a minute. Yes, its terrific to be able to update everyone in my life that cares to look at a screen somewhere on a phone or computer or in an update window on their "dashboard" about whatever it is that I'm thinking about eating for lunch in ten seconds, or to send them a picture of it as supporting evidence should I have the correct data plan and phone type. Yes, oh my goodness yes its great to be able to execute financial transactions "securely" (that's not going out of quotes, ever. Even talking to the teller at the bank isn't secure if you want to be paranoid/exact about it,) at all hours, in all manner of ways.
So, what's not to love?
The sheer volume of data is just beginning to become manageable in quick-search interfaces. The number of times I'm screaming like an angry monkey and throwing my keyboard around in a given day due to screen lock because of a lack of --pause-- in quick search mechanisms in some apps and sites is at around 4 to 10. So, I propose the next time you consider adding/updating a quick search mechanism, put in an automatic 300ms delay before it does ANY processing. ANY. AT ALL. DON'T EVEN CHANGE THE COLOR OF THE TEXT BOX USING CSS, I DON'T CARE HOW FEW CYCLES IT WILL TAKE.
Properly staged change priority, or more accurately, why don't 90% of public collaborative situations have decent version control, or as its politely called "revisions." Why don't web hosts (our company included) force users to switch to using version control for all file management? The time it takes to set up a proper repository in any of the systems, set up the connections to it, deploy files from those connections and justify that time to a client is, well, a little obscene right now. Think of the time it would save in sheer annoyance for you as a webhost to be able to say or you as a client to hear the phrase "oh, just restore that file, here's how" instead of "sorry, that's gone. GOOD LUCK!"
That, and for all the command-line junkies (a group of which I am still a member, though not card-carrying,) before you say "well its not that hard to set it up, just use github or google code or something, and just use the command line client." Shh, you're pretty. Try writing up a FAQ for either GIT or SVN that works on all realistically potential clients. Now, try writing it up not using command line execution. Now try integrating an easy version control server setup into a quick-deploy routine that moves files live at a click of a button. Yes, a button, not an SSH terminal trigger.
Right, so what I'm saying is two-fold: Better, faster graphical interfaces both web and client-based need to be made for both the server management and client side file management of repositories. These interfaces then need simple integration into existing hosting environments.
I say these are both possible, however it will most likely involve a creation of a second-tier of version control, the layman's version control system, one that not only handles file versions on multiple platforms, but simplifies the check-in/check-out procedures and has "deployment" hooks for dumping the files to a public area (i.e. the public web directory for that given site, or portion of that site.)
I'm not saying ALL VERSION CONTROL ALL THE TIME. Having multiple instances of large backup files from another system on a site is, well, a horrible idea storage-wise.
So, not all the time, but for basic files, its kind of critical.
As far as the current state of interactive apps goes, things are great, improving quickly, and I'm enjoying it.
side note about this post:
I had attempted to use Google Wave to post this, but bloggy isn't yet ready for prime-time, so instead of it posting live, it made the wave public which proceeded to introduce me to two people I'd never met before, both of whom were very nice. Kind of funny, given the subject matter.
One person asked "is this a review of wave or something?" and I realized in a way, it was, but more accurately a review of dynamic apps and user interaction. The changes in thought that have come by the Wave team introducing Google Wave, the brains behind the various web-based chat clients (Meebo, Trillian, and others) and the version control community as a whole have created these paths that we are now travelling, mostly as children poking the walls to see if we can go further, but here and there we innovate and build whole new structures outside the bounds of what we thought previously to be possible.
- in Taiwan
- working remotely for clients in the U.S.
- actively communicating with people in all areas of the U.S. and Taiwan in real-time
- sharing dynamically updated data, documents, resources, mixes, remixes and images with people all over the world
I would have said "who? What? WHY?"
So here I am, glamorously using Google, Skype, Audioscrobbler, SoundCloud, Twitter, Facebook, LinkedIn, the gamut of social and business communication applications that are based on servers all over the world (but mostly the U.S.) and therefore able to maintain connections with so many people, in so many ways.
Glamorous? Yes, of course I exaggerate. Its not glamorous to type everything you want, but having shortcuts on my desktop to everything would make my desktop unusable. I quick search everything, typing keywords and shorthand notes that are in titles and filenames. As a result I get things done ridiculously fast, and the only limit is the amount of memory on my system (which I need to upgrade, badly.)
The downside of global communication is the big red "OPEN 24 HOURS" sign attached to my head. Thankfully my phone doesn't ring at 12 noon U.S. time and 1am my time, and my business partner and I are able to maintain good relations at "reasonable" hours for the both of us. Add to that extensive logging of conversations, we're not trying to remember "what did he say last night when I was falling asleep on the keyboard?"
However, the client-side of things takes a toll, everything's expected to move faster, easier, as it SHOULD, but as things move more quickly, the quirks of "speed" become evident.
Yes, its insidiously fast to type the first four letters of something and have it open in 0-4 keystrokes afterwards. Yes its great to be able to receive and reply in less than a minute. Yes, its terrific to be able to update everyone in my life that cares to look at a screen somewhere on a phone or computer or in an update window on their "dashboard" about whatever it is that I'm thinking about eating for lunch in ten seconds, or to send them a picture of it as supporting evidence should I have the correct data plan and phone type. Yes, oh my goodness yes its great to be able to execute financial transactions "securely" (that's not going out of quotes, ever. Even talking to the teller at the bank isn't secure if you want to be paranoid/exact about it,) at all hours, in all manner of ways.
So, what's not to love?
The sheer volume of data is just beginning to become manageable in quick-search interfaces. The number of times I'm screaming like an angry monkey and throwing my keyboard around in a given day due to screen lock because of a lack of --pause-- in quick search mechanisms in some apps and sites is at around 4 to 10. So, I propose the next time you consider adding/updating a quick search mechanism, put in an automatic 300ms delay before it does ANY processing. ANY. AT ALL. DON'T EVEN CHANGE THE COLOR OF THE TEXT BOX USING CSS, I DON'T CARE HOW FEW CYCLES IT WILL TAKE.
Properly staged change priority, or more accurately, why don't 90% of public collaborative situations have decent version control, or as its politely called "revisions." Why don't web hosts (our company included) force users to switch to using version control for all file management? The time it takes to set up a proper repository in any of the systems, set up the connections to it, deploy files from those connections and justify that time to a client is, well, a little obscene right now. Think of the time it would save in sheer annoyance for you as a webhost to be able to say or you as a client to hear the phrase "oh, just restore that file, here's how" instead of "sorry, that's gone. GOOD LUCK!"
That, and for all the command-line junkies (a group of which I am still a member, though not card-carrying,) before you say "well its not that hard to set it up, just use github or google code or something, and just use the command line client." Shh, you're pretty. Try writing up a FAQ for either GIT or SVN that works on all realistically potential clients. Now, try writing it up not using command line execution. Now try integrating an easy version control server setup into a quick-deploy routine that moves files live at a click of a button. Yes, a button, not an SSH terminal trigger.
Right, so what I'm saying is two-fold: Better, faster graphical interfaces both web and client-based need to be made for both the server management and client side file management of repositories. These interfaces then need simple integration into existing hosting environments.
I say these are both possible, however it will most likely involve a creation of a second-tier of version control, the layman's version control system, one that not only handles file versions on multiple platforms, but simplifies the check-in/check-out procedures and has "deployment" hooks for dumping the files to a public area (i.e. the public web directory for that given site, or portion of that site.)
I'm not saying ALL VERSION CONTROL ALL THE TIME. Having multiple instances of large backup files from another system on a site is, well, a horrible idea storage-wise.
So, not all the time, but for basic files, its kind of critical.
As far as the current state of interactive apps goes, things are great, improving quickly, and I'm enjoying it.
side note about this post:
I had attempted to use Google Wave to post this, but bloggy isn't yet ready for prime-time, so instead of it posting live, it made the wave public which proceeded to introduce me to two people I'd never met before, both of whom were very nice. Kind of funny, given the subject matter.
One person asked "is this a review of wave or something?" and I realized in a way, it was, but more accurately a review of dynamic apps and user interaction. The changes in thought that have come by the Wave team introducing Google Wave, the brains behind the various web-based chat clients (Meebo, Trillian, and others) and the version control community as a whole have created these paths that we are now travelling, mostly as children poking the walls to see if we can go further, but here and there we innovate and build whole new structures outside the bounds of what we thought previously to be possible.
Comments
Post a Comment
Be nice.