October 22, 2003
This version adds support for all common real-time sample rates up to 192kHz (previously hardwired to 44.1k). Included are a number of usability enhancements such as new patcher right-click menu items for Replacing, Inserting and Bypassing contraptions without having to connect and disconnect patch-cords; and the ability to define a "default" document used as the basis for all newly created documents. There is a new FrequencyShifter contraption, and Mute and Solo buttons have been added to the Mixers.Have fun!
SmartDocuments and InfoPath
I've done a little SmartDocuments development, and don't find it easy to share his enthusiasm completely: the developer documentation is difficult to parse, and the experience wasn't a whole lot of fun. I do think the concept is powerful and important, and opens some fascinating possibilities - just a note of caution if you're thinking of diving in with both feet.
The potential of SmartDocuments is quite interesting, really. It appears to be part of a very broad "reclaim the desktop" strategy, where integration traditionally seen as "enterprise-scale" -- workflow, content management, legacy systems context -- becomes part of the Office experience, instead of stovepiped into separate desktop- or browser-based application interfaces. Which is a smart strategy, both in terms of an Office hegemony and enhanced user experience.
October 21, 2003
Home from home
Groove Networks Takes the Microsoft Office System "Out Of the Office". Today is Office2003 launch day, and we have something to say. Especially about SharePoint and InfoPath:
The Groove Mobile Workspace for Windows SharePoint Services uniquely extends the value of InfoPath 2003 by transporting InfoPath forms solutions from the server to the PC, allowing XML forms-based information to be captured anyplace at anytime. With Groove Workspace, mobile InfoPath users can literally bring their XML forms solutions with them wherever they go, and provide third parties with secure access to forms. The combined Groove Workspace, Windows SharePoint Services and InfoPath 2003 solution is optimal for field-level or cross-company business processes that require extensive information gathering, such as sales, sourcing, procurement, customer relationship management, and more.The Groove/InfoPath integration really is very very cool. (Full disclosure: I built this!). It's still very very cool. Useful, too.
Check it out. You'll need the Groove 2.5i maintenance release, and a Professional license. Then: "create shared space" - "standard toolsets" - "Mobile Workspace for SharePoint", and point it at a SharePoint site which includes an InfoPath form library.
Also notable because we embed a small Groove Web Services client inside InfoPath. This brings pieces of Groove -- member awareness, instant messaging and invitations -- right into the Office application.
October 20, 2003
Game Neverending, meanwhile. Looks fun; MOO-like server, and a very good mixture of Flash and Web user interface: the main environment is Flash, but most things are web-accessible too. There's even the beginnings of a web services interface (this is cute).
And Liz Lawley notes, Disney are just launching a "ToonTown" MMORPG, for kids. For ten bucks a month (!!). See, there is a market for this stuff. There's a business we could decentralize nicely, eh?
Mica is a system for building network-accessible multiuser portable applications. It is a programming language and object environment designed to be accessible by more than one programmer at a time. It includes an implementation of a mostly pure object oriented language. Automatic persistence, reflection, strong encapsulation, multiple dispatch, and run-time security are some of its features.A post-MOO language design. It would be really interesting to have some of these environmental features on a Groove base, wouldn't it? Language-transparent persistence. Singleton (instance) objects with prototype inheritance. (Distributed XML, too?) Hmmm.
Which reminds me that one of the unusually smart things about LambdaMOO was its security model, in a world where "untrusted code" was everywhere. Individual verbs (methods) execute with the privileges of their author, as I remember. Which is neat (if your world includes wizards to do the dirty work)...
October 15, 2003
Alarmed and suspicious
Electronic voting machinations in the Independent:
Alarmed and suspicious, a group of Georgia citizens began to look into last November's election to see whether there was any chance the results might have been deliberately or accidentally manipulated. Their research proved unexpectedly, and disturbingly, fruitful."Enough to stand your hair on end".
October 14, 2003
In the real world, we have conversations in public, in private, and in secret. All three are quite separate. The public is what we say to a crowd; the private is what we chatter amongst ourselves, when free from the demands of the crowd; and the secret is what we keep from everyone but our confidant. Secrecy implies intrigue, implies you have something to hide. Being private doesn't. You can have a private gathering, but it isn't necessarily a secret. All these conversations have different implications, different tones.
October 11, 2003
Skip lists are a simple data structure that can be used in place of balanced trees for most applications. Skip lists algorithms are very easy to implement, extend and modify. Skip lists are about as fast as highly optimized balanced tree algorithms and are substantially faster than casually implemented balanced tree algorithms.Very nice. The paper is completely self-explanatory, and the cookbook has a little more detail, but if you want to see the illustrations in action, here's an applet to play with.
October 10, 2003
Please remember one extremely important fact. It does not make sense to have a string without knowing what encoding it uses. You can no longer stick your head in the sand and pretend that "plain" text is ASCII.It hurts every time I have to say that, too. Luckily, I think, everyone I work with understands it now.
October 09, 2003
The debugger; statement doesn't seem to be very widely known. It brings you into the script debugger. (For scripts in IE, you'll need to enable script debugging, by unchecking Tools - Internet Options - Advanced - "disable script debugging"). As to which debugger you get, well, I haven't worked that out yet; I get to choose from a list of the half-dozen installed script debuggers. Strange that Microsoft should produce so many, really.
October 06, 2003
Groove and WSS
Laurent Kempé: "That's it !!! Groove is working with the Windows Sharepoint Services. I just had a try after the update of Groove Workspace 2.5i and it WORKS". Indeed. I'll have more to say about this later.
October 04, 2003
Jon Udell takes a look at collaboration in Microsoft's Office 'system':
Here’s a trick question: What is Microsoft’s collaboration server? The answer used to be obvious: Exchange. Now it’s not so clear. Suppose you want to hold a discussion. You can still do that transiently in an e-mail thread, or with more permanence in an Exchange public folder. But Live Communications Server injects a new ingredient into the mix: IM-style presence. If you can see that the participants in the thread are online, you may want to switch to chat mode. Or you could launch a discussion on a SharePoint site that displays presence indicators. Even more intriguing, an Office document can now be a locus of presence-enhanced SharePoint collaboration.Indeed. Although SharePoint is the closest thing to that. Actually I think there is an underlying theme, just Microsoft didn't realize it yet...
October 03, 2003
devs who are used to the VB-style "with" -- which is a syntactic sugar -- fall into the trap of believing that JScript "with" is also a syntactic sugar when it emphatically is not! ...it allows devs implement dynamic scoping rules in a lexically scoped language -- but 99.9% of the developers who use "with" are looking for the sugar, not dynamic scoping!
Daniel Hedrick: "I've been using Groove off and on for a year or so, and I'm hooked".
October 02, 2003
Matt Webb has a great series of posts exploring presence and the way people interact in virtual environments.
I think we've found that virtual reality isn't necessary for presence, only that the behaviour of something that appears to be "human" is transmitted through the behaviour of the medium.We're at an interesting stage, where lots of communications technology is becoming "socially invisible" - mobile phones and WiFi-enabled computers are everywhere, taken for granted. There's a two-way movement of models and ideas between the real and virtual environment.
Two people standing in a park, waiting for a call. The phone rings. Guy ('tis his mobile) answers; Gal, although obviously keen to become a part of that virtual place, has to stand and wait for the call to be done. A three-way online chat can happen fluidly and quickly - but real-world telephone "conference setup" is wickedly complicated... why?
Dave Winer says
...it would be more convincing if Groove were open to competition, or at least open to being built on. When they came out with web services interfaces, finally, after years of waiting, the excitement was dampened because it didn't work with the programming environment I use. Maybe they are open to be extended, but, practically are there any extensions from people who are not working at or closely with Groove?OK, let's look at that again.
SOAP-based access to "local system services" - collaborative services based on your desktop, in our case - really is a huge deal. Of course we're working with Microsoft kit more than anything else - as I hinted earlier, their development environment support for building web services clients really is exceptional - you hardly need to know that you're calling remote services, let alone the mechanics of how the message gets dispatched from A to B. That ease-of-access will be very important in the future, I think.
update: Jeff points out the screenshot isn't OS X, just a nice skin! Confused me, anyway.
October 01, 2003
"Shrub is reluctantly saying one thing and Cheney goes on national television and flat lies through his teeth. If those are his teeth". Ha.
Workspaces and email
Anyone who is doing a critical business process online that involves substantial dialog between individuals should NOT be using email at this point in history, and many no longer are.and,
If you have work to do with others, online, try workspaces. There are many different types - from Groove if you like client-based mobility, to SharePoint if you like using Websites... you'll only visit eMail as a low-priority background task, much as you do when sorting through your physical mail at home. You'd never do important work through your home mailbox, would you?
Update 10-02: Sean and Scott add:
I've tried probably 300 different ways of organizing my inbox over the years and nothing works all the time for every situation.... What I want is one tool that does what Groove, Sharepoint, and Outlook do for me that works in Offline and Online modes and is one tool. It's really more of an issue of focusing on what the work is that people use the tools for as opposed to the tool itself...
The customer is always right... even when their requirements aren't clear (are they ever?). When the specifications are in flux, one sensible response is to build a framework.
Frameworks, after all, are a negotiation with the future.
I've been working with an external customer recently, on a reasonably small integration component of a Groove deployment. There's an Oracle database, populated nightly from SAP and Siebel systems, which needs to drive some activity in custom tools in Groove spaces; and some of the information being used in Groove should be sent back to the Oracle database, where it'll be directed onward to SAP, Siebel or wherever.
So far, so good. The outline requirements are clear, and reasonably straightforward; I'll use Groove EIS ("bot server") to build a single integration point, 24/7, and the bot will be a member of all the relevant spaces. Since I've worked with EIS before, it was quite straightforward to build out the skeleton of my application: a scheduling strategy, some "space lifetime" management, that sort of stuff.
The actual data transfer (being the raison d'etre of the bot) was a bit more murky, though. To build the bot I'll need: the Oracle table schemas, the Groove tool schemas, and a map of how the data moves from A to B. None - repeat, none - of this information was available.
It quickly became clear that the schemas - and the mechanics of the data transfer - will only be absolutely frozen a few days before this system goes into production. That's not anyone's fault; there are at least four different groups working on the pieces of this, and everyone's working hard.
My bot, sitting pretty on the critical path, needs to be able to accommodate changes quickly. I suspect that there'll be customer-driven changes even after we roll this thing out; and I definitely don't want to be rebuilding and redeploying code for each change.
So, of course, I set to building a framework. My bot reads a configuration file (XML), which specifies exactly how to connect to the database, how to find the tools, and any number of "jobs" which move data from one to the other. There's a mapping table, to take field X into field Y. There's a primitive transformation syntax, to calculate things which aren't a simple field transfer.
So, you can edit the configuration file without even shutting the bot down; changes will take effect immediately. Code become data. But now, the configuration file almost looks like a programming language of its own... state, loops...
I've used a similar strategy a few times, and it's usually worked pretty well. One downside is that a sufficiently powerful configuration syntax (in XML - so it's verbose and not necessarily too readable) becomes really really difficult for a "non technical user" to maintain.
On the other hand, I couldn't justify the time and expense of writing a full "configuration editor wizard".
Maybe InfoPath would do that job really well, though. It's worth considering for next time. (That link URL says "preview", but I'm sure it's RTM already...!)
One lesson: if you're going to build a framework, decide it early. That way you'll get a good, flexible, road-tested framework. Plan for re-use. And make it easy to use right...
[ /* more blogroll to follow */ ]
The views expressed on this weblog are mine alone and do not necessarily reflect the views of my employer.