The question was raised in the discussion on pricing, but I think it's of interest to all...
Does/will this sync directly from iCal to Google, or does it go through another server?
Personally, if it goes through another server, I'll be looking for another solution unless the price is extremely low. If it speaks directly to Google, without a "middle-man", then I'm down for it!
Spanning Sync consists of two components: the client that runs on your Mac and a service that runs in our datacenter, which in turn talks to Google. We chose this architecture for several reasons.
First and foremost it allows us to constantly improve the system--by fixing bugs, adjusting to the frequent subtle changes in the Google Calendar API, and adding new functionality--all on the server, without forcing our users to install updates on their machines.
It also gives us the ability to spot and solve problems sometimes before our users even notice there's something wrong.
Finally, it leaves open the possibility providing sync services between online services. For instance, our next product will synchronize calendars between Google and Salesforce.com.
We appreciate the privacy and security concerns of our users and take steps to make sure that their private data stays private. We don't store any calendar data; we only process it. Our background is in providing similar services for our customers' most sensitive corporate data (see http://spanningsalesforce.com), and we consider each user's calendar data to be no less important.
> Personally, if it goes through another server, I'll be looking for > another solution unless the price is extremely low. If it speaks > directly to Google, without a "middle-man", then I'm down for it!
I find the worry about a 'middle man server' pretty ironic, especially since we're discussing this through Gmail/Google's Group servers, and we're talking about a Google Calendar service. The company who's pioneered data retention for advertising and marketing purposes.
Spanning Sync isn't going to peek into our personal and business lives, and when you think about it, they aren't the only ones who might have access to our data. If you have a .Mac account, that means Apple knows when you've scheduled your next business meeting and when to pick up Sally from soccer practice.
This is a legitimate company, and if anything their access to your data should increase the value of the product, given how much is theoretically at stake, and the responsibility they have in protecting your stuff.
Do you want to pay for a $5 dollar body guard, or a $100 body guard?
Not to say that I think Spanning Sync should cost $100, mind you. :)
Yikes. I'm probably gonna bail out now that I know Spanning Sync will act as a middle man. Why? I don't want to deal with a subscription fee. I don't want to worry about SS's servers being available each time I sync my calendars. I get the impression that Spanning Sync is used to dealing with "companies" rather than individual Mac users. (The types of users who flock to programs like TextMate, AppZapper, Disco, Transmit, and NetNewsWire.) I don't want a program that "leaves open the possibility providing sync services between online services." I want a small utility that does one thing and does it well. If you want me to use another one of your services, that's fine. Sell me another product when the next one is ready.
I appreciate Spanning Sync's desire to catch bugs and implement fixes transparently on the server side without users noticing, however many of the Mac applications I use on a daily basis are constantly checking for updates - and most of them install themselves automatically after prompting me for approval. I don't think you're going to turn off users by releasing an occasional update. If anything, I think they'd appreciate the fact that you're actively working to improve their experience.
> I find the worry about a 'middle man server' pretty ironic, especially since > we're discussing this through Gmail/Google's Group servers, and we're > talking about a Google Calendar service. The company who's pioneered data > retention for advertising and marketing purposes.
I see the irony (there's plenty), but there is a slight difference. First off, using Spanning Sync's servers adds a third party to the conversation where previously it was just between the user and Google (not counting the network providers of course). Also, I have no choice but to trust Google. They're getting bigger and scarier every day, but so far they haven't given me a reason not to trust them. I don't trust Spanning Sync yet. (I know I'm holding them to a double standard by not giving them the chance to earn my trust, but that's just the way it is for smaller companies I haven't dealt with before.)
Justifying the middle man approach by arguing "it leaves open the possibility providing sync services between online services" doesn't make sense to me. Currently, (from what I've seen) the preference pane doesn't mention anything regarding syncing with other online services. Therefore, to add that feature, Spanning Sync would have to release an update for their users to install - something which they want to avoid doing. Until that happens why bother going through their servers? Let the preference pane talk directly with Google. Or, better yet, offer two versions. An inexpensive one that takes the direct approach, and a corporate edition with all the other bells and whistles :-)
Sorry, but playing the middle man will be a deal breaker for me.
Tyler Hall
On Nov 2, 10:30 am, "David Chartier" <dcha...@gmail.com> wrote:
> > Personally, if it goes through another server, I'll be looking for > > another solution unless the price is extremely low. If it speaks > > directly to Google, without a "middle-man", then I'm down for it!I find the worry about a 'middle man server' pretty ironic, especially since > we're discussing this through Gmail/Google's Group servers, and we're > talking about a Google Calendar service. The company who's pioneered data > retention for advertising and marketing purposes.
> Spanning Sync isn't going to peek into our personal and business lives, and > when you think about it, they aren't the only ones who might have access to > our data. If you have a .Mac account, that means Apple knows when you've > scheduled your next business meeting and when to pick up Sally from soccer > practice.
> This is a legitimate company, and if anything their access to your data > should increase the value of the product, given how much is theoretically at > stake, and the responsibility they have in protecting your stuff.
> Do you want to pay for a $5 dollar body guard, or a $100 body guard?
> Not to say that I think Spanning Sync should cost $100, mind you. :)
For me it's not so much a matter of trust or a concern over privacy or security.
Simply put, if it involves a subscription, I'm out. One time flat fee, no reliance on a 3rd party system that may or may not be here a year down the road, forget it.
I'll lay odds that before the middle of 2007, Google will have a (beta) application available for free that will sync iCal with Google Calendar. Not to mention something to sync Google Cal with Outlook for the Windows users.
Now that I think more about it, I'm starting to agree with others that I would prefer a stand-alone app that simply uses the Google API, relying on updating the application for fixes and improved performance, though it probably won't be a deal breaker for me.
On a broader scale, considering the demographic this app is going to appeal to, I"m willing to bet most of your users aren't going to mind the occasional update either. Most users who seek out this kind of functionality are used to the application update process, and on TUAW we've blogged services/frameworks that allow developers to build self-updating into the application itself. I believe it's called Sparkle, and Adium is a good end-user example of it; the app tells you there's an update and allows you to download or ignore. if you download, it installs the update itself, and prompts you to restart the app. No fuss, no disk images, no zip archives or manually replacing files buried in some app support folder somewhere.
I should append this. I didn't mean to give the impression that anyone should wait for or rely on Google to ship something that does this. On the contrary... If you can beat them to the punch and keep the feature set a notch or 2 above whatever Google comes out with, you'll be able to build a user base and make money off of it.
There's clearly plenty of concern about the intermediary aspect to this service. Bear in mind that other services I pay for (Blinksale, FeedBurner TotalStats, FeedLounge) cost US$5pm, Strongspace slightly more. It would *have* to be a low monthly fee.
> There's clearly plenty of concern about the intermediary aspect to this > service. > Bear in mind that other services I pay for (Blinksale, FeedBurner > TotalStats, FeedLounge) cost US$5pm, Strongspace slightly more. It > would *have* to be a low monthly fee.
Unfortunately, a lot of those other services are subsidized by advertising; Spanning Sync doesn't look like it has much opportunity for this, since it runs as a background daemon calling Google Calendar and simply syncing your items transparently. There are no webpages in between with which Spanning Sync can display ads.
There's also the topic of use and value - none of those other services have anything to do with what Spanning Sync is capable of. Simply saying "well I pay $5 for this completely unrelated online service" doesn't bear a whole lot meaning to Spanning Sync.
Wow. This completely changes the picture. In my mind an app such as this is worth about $10-15. Total. There is no reason a middle-man server should be required. I would not get near this app with a 10-foot pole if it involved any type of monthly or yearly subscription fee. $5 is not in any way a low fee for this type of app. That's $60 per year for goodness sakes! The only Mac app I've bought that cost more than $39 was Final Cut Express HD. Even the iLife suite costs $49 (with my student discount). Unless you can provide a stand-alone solution, or guarantee that there will be no subscription fee, I'm out.
On Nov 2, 10:03 am, "TimBo" <tim...@gmail.com> wrote:
> The question was raised in the discussion on pricing, but I think it's > of interest to all...
> Does/will this sync directly from iCal to Google, or does it go through > another server?
> Personally, if it goes through another server, I'll be looking for > another solution unless the price is extremely low. If it speaks > directly to Google, without a "middle-man", then I'm down for it!
Having a middle man seems like a bad idea to me. With this there's also the worry of your servers being hacked and personal information being leaked, no matter how remote. I trust Google with my information! While they use it to do targeted advertising and anything else I'm confident that it isn't getting into the wrong hands. For a company of their size (and stock market value) it would be a PR disaster to have major leaks or obvious use of "private" information for other purposes.
For this solution it doesn't seem that there's any need for you to do the processing on your server. I assume you're talking to a public API at Google and the Mac is sending raw information to you. Why not do it all in a single client side app.
Plus: if you're going to offer a subscription model through your servers there's even more chance that someone will come along with a single solution that doesn't require the servers and make this tool obsolete.
If this really turns out to be the model I just might go about writing this myself and make it free.
Jon
On Nov 4, 8:03 pm, "Ricky" <rickybloomfi...@gmail.com> wrote:
> Wow. This completely changes the picture. In my mind an app such as > this is worth about $10-15. Total. There is no reason a middle-man > server should be required. I would not get near this app with a > 10-foot pole if it involved any type of monthly or yearly subscription > fee. $5 is not in any way a low fee for this type of app. That's $60 > per year for goodness sakes! The only Mac app I've bought that cost > more than $39 was Final Cut Express HD. Even the iLife suite costs $49 > (with my student discount). Unless you can provide a stand-alone > solution, or guarantee that there will be no subscription fee, I'm out.
> On Nov 2, 10:03 am, "TimBo" <tim...@gmail.com> wrote:
> > The question was raised in the discussion on pricing, but I think it's > > of interest to all...
> > Does/will this sync directly from iCal to Google, or does it go through > > another server?
> > Personally, if it goes through another server, I'll be looking for > > another solution unless the price is extremely low. If it speaks > > directly to Google, without a "middle-man", then I'm down for it!
Wow, this is hugely disappointing. I had no idea this application would involved a hosted solution; this decision really does make very little sense to me. I don't want to have to rely on *two* systems being online and functional before I can sync my data. From a logical standpoint this really does seem like more of creating an ongoing source of revenue rather than a user / customer-centric decision. How does having my data pass through your servers improve my experience?
Short answer: it doesn't. Thousands of software developers fix issues every day and push out updates to their software without forcing users to subscribe to a hosted service - there's no reason for this solution to be any different.
In fact there is one extremely important way in which our service-oriented architecture affects the user experience: continuous improvement. Let me give you an example.
Yesterday we pushed v1.0b2 (106) of the client software to a new group of beta testers. Within minutes, one of them had run across a bug. He didn't report it, but since the request and response went through our servers, our own error reporting function caught it and alerted us. Within minutes we were able to fix the bug in the server code and push the fix to the live servers. When the user synched again 10 minutes later, the bug had been fixed. He literally never had to lift a finger.
If Spanning Sync didn't include a service component, we wouldn't have discovered the bug until someone decided to report it, and once we had fixed it, every one of our users would have had to install a new version of the software. Since we wouldn't want to build and distribute a new version every time any individual bug was fixed, they'd be forced to live with that bug until the next beta release. But our service-oriented architecture allows us to continuously improve the quality of the service without interruption to the user. That's a big deal to us.
I can understand where you are coming from with the service oriented architecture but I guess I would question why you are getting hesitation from us accepting that architecture if it is so beneficial to us. It is almost a case of customers telling you what they want and you telling the customer what they want. What do you think the results of an open poll of your customers would be if you were to ask them whether they wanted your Service-oriented architecture or stand-alone application that talked directly with Google? Might be interesting.
I certainly hope I'm not trying to come off sounding like I'm trying to tell our users what they want. I'm just explaining the rationale behind a decision thawas made at the outset of the project. The majority of people I've talked to about the issue don't have a strong opinion one way or the other, but then again the majority of people I've talked to aren't active in this discussion group.
We absolutely value the feedback. That's why we created this discussion group in the first place. And we absolutely value passionate users. Please keep the feedback coming. We read every bit of it and take it to heart.
Sounds to me like you need to improve the testing before seeding beta releases. If you have bugs that are that serious the beta should not have gone out. Why I appreciate you don't have a department of testers etc, but surely you have multiple server and some dummy calendars though which you can automate most of the user actions.
If you're looking for a good testing tool, then look into Eggplant. I've used some of this kind of testing and it really does work
> I certainly hope I'm not trying to come off sounding like I'm trying to > tell our users what they want. I'm just explaining the rationale behind > a decision thawas made at the outset of the project. The majority of > people I've talked to about the issue don't have a strong opinion one > way or the other, but then again the majority of people I've talked to > aren't active in this discussion group.
> We absolutely value the feedback. That's why we created this discussion > group in the first place. And we absolutely value passionate users. > Please keep the feedback coming. We read every bit of it and take it to > heart.
> Yesterday we pushed v1.0b2 (106) of the client software to a new group > of beta testers. Within minutes, one of them had run across a bug. He > didn't report it, but since the request and response went through our > servers, our own error reporting function caught it and alerted us. > Within minutes we were able to fix the bug in the server code and push > the fix to the live servers. When the user synched again 10 minutes > later, the bug had been fixed. He literally never had to lift a finger.
This sounds like you need to be more confident and stringent in your beta testing / pre-release QA rather than a benefit for the actual release-using customer. If your release-quality software is going to require so many frequent updates that it needs to be remotely hosted there's a bigger issue than just a poorly thought out business plan.
I'm not trying to be an ass about this, but let's be 100% honest here: we're dealing with a system to sync calendar data between a computer and a **free** service. There's absolutely no reason that this needs to be so complex that it requires client and server-based software when there's an API available.
So keep it as it is during the beta, and once you have stable code, migrate it all to the client?
I have to agree on this point, I do not like the middle man. Not because if privacy issues, but because I do not want a subscription based service, I want to buy an app. And I want to know that said app keeps working if for whatever reason your company goes bankrupt/your server explodes/someone trips over the power cord/whatever...
While this is something I'd really like, I personally will not pay for a subscription, and the middle man makes me very doubtfull about spending my €
> I have to agree on this point, I do not like the middle man. > Not because if privacy issues, but because I do not want a > subscription > based service, I want to buy an app.
Whether or not there's a middle man has absolutely no bearing on how they decide to charge (app or subscription).
All things considered, I prefer the middle man. Maybe I'm just getting old (26), but I'm getting a little tired of endless application updates and 1.0.2.45 beta 15 built #4198 version bumps, so the way they're rolling here is almost a welcome change.
> All things considered, I prefer the middle man. Maybe I'm just > getting old (26), but I'm getting a little tired of endless > application updates and 1.0.2.45 beta 15 built #4198 version bumps, > so the way they're rolling here is almost a welcome change.
But you still have a client side application to keep updated.
> But you still have a client side application to keep updated.
Yea, but the idea is that they don't have to do it nearly as often. If everything was client side, they'd probably have to issue updates daily, if not many times per day, at least on occasion. Every change to the API Google makes would mean another update for us all to download and install. I don't know about you, but even I have better things to do sometimes than to stay glued to my RSS reader, waiting for Google to publish another "we're having fun with our software, again" post.
Any plugins and clients that work with del.icio.us and Flickr are great examples - every time those companies change something about their system or their APIs, everyone's software breaks, and we get a bunch of "OMG MY SOFTWARE BROKE HOW AM I GOING TO GO ON LIVING!!" tips submitted at TUAW. Then everyone has to wait until the respective developers of those clients get pummeled enough with the same support emails to have time to update their software - nevermind if they're in class, on vacation or getting married. Then all us news sites have to post that these software apps were updated to version 1.0.3.8 build 3418 for the fourth time this week while Company X is dorking around with their software, system and APIs.
It's a retarded process, this is 2006 - it shouldn't be this way.
The model of Create Beta - Rease to Users - Users Update and Relaunch has worked in the past and is working currently.
Everyone is very used to doing this, ESPECIALLY BETA TESTERS. So your argument above of that one incident doesn't really stand.
Why is it so hard?
The Dirty way: fix bug, recompile, update your website with new download. Send RSS or email notification of update
The Clean way: Have the client code (especially for the beta) phone home every 24 hrs looking for new updates. Fix bug, recompile, update self-update service. On the users side, we see a "New version available, Yes/No to update".
The Convoluted way: Component-ize your code so half of it is on a client and the other half is on a server. You still have to update the client using the Dirty way (albet less frequently) but you make updating the core of the App very easy on your end at the expense of pissing off your users and loosing business.
Trust me, most people have no problem getting an update. It's actually part of the Mac user experience and I personally always love it. And during the beta period, christ... who cares.. participating in a beta implies reinstalling the app a bazillion times.
> The Clean way: > Have the client code (especially for the beta) phone home every 24 hrs > looking for new updates. Fix bug, recompile, update self-update > service. On the users side, we see a "New version available, Yes/No to > update".
Right, and with Sparkle available (http://andymatuschak.org/pages/sparkle) for FREE to any Cocoa developer, there is no excuse for a clean auto-update. I have many apps that use the Sparkle framework to auto-update, and it works flawlessly. As a beta tester, I wouldn't mind at all if it updated itself many times a day. As the app progresses and becomes more stable and mature this will slow down to probably once per week at the most. I could even handle once per day if necessary. I just don't want a middle man. It's not necessary.
I'm with everyone else and am against a third party between me and google. I was one of the first to sign up for the beta but ditched it when i found out how it works. And this talk about google 'just playing with the API', keep in mind calender is still a beta product and the API wont freeze till calender is released, google has a right to change the API during this period. Perhaps this just isn't the time for the spaningsync product if breakage is as often as it is being mentioned and they are trying to integrate with a beta product. And if we are beta testers, we are used to (or should be) updating our app everyday and even having it wipe out our calender from a programing error.
Don't get me wrong, i totally love the idea of this app and will buy it in a second if it is a standalone app even if it automatically updates every so often for what ever reason.
I'm with other users, I WILL NOT be using any subscription service and most certainly am not paying more than $10-15 one time payment for this software. I understand and apreciate the thoughts that creators of this software have about catching the issues and not causing any users discomfort by "not forcing" them to re-install the software when the new version comes up but that's just not enough. When i use google's email, calendar, chat, forum i entrust my personal information to this company and i do so with understanding that the exchange is only between the two parties. Having Spanning Sync merely "process" the information does not help with my privacy concerns. Being somewhat familiar with software architecture i tend to question the motives of anyone that would create a software that instead of communicating directly client to server would have designed a "middle man", no matter how noble the idea of fixing the bugs found in the process is.
In short, i will not be using this software and will immediately look for alternative means of accomplishing sync. Furthermore i'm sure google will release something soon enough that will do all of these things and without a "middle man", sort of like what happened with Google Notifier.
|
