“No Code” is Not Enough

I’m very, very tired of seeing/hearing the phrase “no code”. I see presentations advocating “no code” solutions for SharePoint. I see advertisements from companies who proudly declare that they’re all about “no code” apps. The issue isn’t confined to the world of workflow, but I see it arise in workflow-land readily and frequently.

It’s not that eliminating code isn’t a useful thing — it is — but when authors/speakers lead with the phrase “no code”, it suggests that they’ve likely missed the point. To wit:

“No code” doesn’t really help users.

The implication of “no code” is that it’s easier, and that “even users can do it”. Well, “no code” does not always mean “easy”, let alone user-accessible.

Take SharePoint Designer, for instance. Users aren’t being done any favors if they still have to do things like increment counters, check flags and semaphores, initialize variables, stage a set of dictionaries in order to call a web service and parse the results afterwards, or poll for results. Actually, add calling web services to that list. 

People who think like developers and DBAs see value in data models, but users just see content (documents, lists, images, etc.). They need to know what they’re working with, not see it abstracted into generic objects.

Other offerings may look friendly at first glance, but every drag, drop, configuration choice, and term in the user interface belies a developer mindset bias.

Still other offerings all but require the user to learn a new language to get anything done; it may be a visual/graphical language, so it qualifies as “no code”, but it’s still complex and hard to follow without training. For example, to get a manager to even understand a process model authored in Business Process Modeling Notation, you need to teach her how to read BPMN. To get a business user to author BPMN, you need to teach him a whole new discipline.

“No code” doesn’t really help IT.

“Citizen Development”, as Gartner puts it, has immense potential. But ask many IT professionals what they think of all those elaborate Excel, Access, InfoPath, and SharePoint Designer solutions and you’ll very likely get an earful of complaints.

Just locating and keeping track of those no-code solutions is difficult enough. Monitoring bad behavior (e.g., runaway loops, excessive network and database I/O, etc.) gets tricky. Understanding what is affected when a no-code solution is changed/deleted is hard. Figuring out who will maintain existing no-code solutions when the author leaves the company can get nasty, let alone the odds of the new no-code developer being able to understand what the previous person did.

Recent developments in Microsoft’s approach to business intelligence excepted, all too often, “no code” means “no responsibility”.

“No code” gives an impression that code is bad.

Believe it or not, sometimes code is actually pretty attractive. Why? Code can be versioned. Code can be profiled. Code can be validated. Code can be optimized. Once you have to think a developer’s thoughts, you should at least have tools equal to the task.

It’s not about “no code” — it’s about user focus.

Many of us want users to have the ability to build some solutions for themselves. Many organizations need this if they’re to get past backlogs and bottlenecks. If that’s to be the case, users should see concepts they find familiar. Or at least not entirely unfamiliar. Put another way:

Not having to code like a developer is not enough.
Not having to think like a developer is the goal.

“Power users” shouldn’t have to denote users who can act like developers, but rather users who can understand a business problem, the content, the process, and the logic needed to make something happen. They deserve tools that reward that thinking. Those tools should be governable and extensible, too — without getting in the way.

If all you think you need to do is free them from coding, you’re going to have to do better than that.

The Services Are The Platform

I can’t take credit for the idea; I got it from something James Urquhart wrote for GigaOM. But I’m going to paraphrase it, extrapolate from it, and talk about what it could mean for Office 365.

The cloud is teeming with infrastructure as a service (e.g., Rackspace, Azure VMs, Amazon EC2), platforms as a service (e.g., Azure .NET, Google Cloud Platform), storage as a service (e.g., Amazon S3), and full-blown software as a service (e.g., Office 365, Salesforce.com, DropBox, Box). There’s a battle going on out there for the hearts and minds of developers and architects, and there are pundits betting on winners.

I’m not sure there’s going to be an out-and-out winner, and I don’t think it matters. An inflection point is coming after which business apps won’t be built on one platform. They’ll be built using the most appropriate services from what may well be a variety of vendors. In other words, the array of services that best fit a need will be the platform on which a solution is built.

Companies that understand this can profit from it. IFTTT does a good job of this with consumer services. Nintex is embracing this for business-focused cloud services in a big way. Several companies are waking up to this, and who wins is likely to involve a combination of pure cleverness, ability to execute, and partnering prowess.  Those that offer services of substance and make them easily accessed via APIs lend themselves to being mixed-and-matched by these kinds of tools.

SharePoint is an interesting case. The whole point of SharePoint has been to provide multiple workloads (e.g., ECM, collaboration, search, BI, etc.) on a common infrastructure. The individual services didn’t need to be perfect (although some of them were great anyway) as long as the overall package was superior to (and cheaper than) buying multiple standalone one-off solutions.

The cloud, however, makes that advantage nearly moot. If I can assemble a set of content, BI, collaboration, and discovery services to do what I want, I won’t care whether they come from a common server platform.  To address this challenge, the services that make up SharePoint will need to be compelling even when standing alone.  You can see this happening with OneDrive for Business. Ditto Project Online. Yammer, too. The BI stuff all but begs to be made available for those who want that and only that.

In fact, to ensure further success, it may be necessary for SharePoint to be carved up for parts. Given that the Office 365 brand is the one that has all of the attention, the services might become the platform there, too.

Don’t Look for *an* InfoPath Replacement. Look for Three.

Some people are seeing the “death” of InfoPath as if the sky were falling. Calmer heads aren’t overreacting, but they’re nevertheless starting to look for a replacement. Before going too far down that path, I’d urge careful thought, because I don’t think anyone should be looking for “a” replacement.

“Forms” means different things to different people. I can think of four:

• Structured Documents – There is information to collect and each piece of it must be identified. The form’s contents need to be a permanent document that can be copied/moved/archived/signed, but we want to be able to parse the contents and do things with them.
• Data UI – There is data living in a database table/SharePoint list, etc., and we want to be able to get at each row/item in an attractive, understandable, easy-to-view-and-edit way.  The form is basically a nice viewport into the data — the data is the important part.
• Solution UI – There’s an overall app that’s the star of the show. It could be a custom solution, a workflow process, a CRM environment, or really anything. They key is that we need to show the user some things and ask them for other things, and the data could come from and go to just about anywhere. And there are likely to be a lot of these forms that work with both each other and with other application assets.
• Standalone Applications – We have a form that’s a document and a solution in and of itself. It stores some data, fetches/sends other data from/to other places, has its own code, or at least its own macros/rules.

Now let’s look at InfoPath with the above in mind…

It was originally conceived as a way of doing Structured Documents from a desktop smart client. Along the way to version 1.0, the team added the Standalone Applications scenario, because at the time — the Office 2003 era — Microsoft’s Office division viewed the world from a client-centric point of view.

By 2007, you could use InfoPath for Solution UI if that solution was a code-based workflow, and in 2010, it worked even in declarative workflows (e.g, SharePoint Designer, Nintex Workflow). 2010 also introduced InfoPath support for Data UI — if that data source was a SharePoint list.

In other words, it tried to be all things to all people. How often does that go well? Let’s see…

• Using InfoPath for Solution UI isn’t a bad idea in theory, but there’s nothing in InfoPath’s designer that knows about the rest of the solution (workflow context, for example, which is one of many reasons Nintex developed Nintex Forms). In addition, those UI assets need to be developed completely independently of the rest of the solution. If you make a change to the data, the workflow logic, the authorization model, etc., you have to make sure the forms are independently updated accordingly.  If code is required, it gets even nastier. It’s no wonder that as early as last year the Office team blog was suggesting a look at Access.
• That led a number of InfoPath people to conclude that the best course of action was to move to the Standalone Application model, throw away “workflow”, and put all of the logic in the form. That’s a problem – a big problem. For decades now, we’ve been taught that solutions should be broken up into a presentation tier, a logic tier, and a data integration tier.  Who thinks cramming process logic and data access into the UI is a good idea? Hopefully no one. Even if you did, how easy to follow was an InfoPath form with a lot of views, field rules, form rules, and embedded code?
• As for the Data UI use case, InfoPath does a fine job of this if you have SharePoint Enterprise Client Access Licenses so you can use InfoPath Form Services. But I hope that’s not the only reason you have Enterprise CALs, because a number of companies have or will disrupt that. Nintex Forms disrupts that, albeit not deliberately. Heck, even CodePlex projects like Forms7 disrupt the Data UI use case.
• Actually, InfoPath is an excellent structured document product. Then again, that was before all Office documents became XML documents in 2007.

So if not InfoPath, what?  There is no one replacement.  There are three.  Use the right tool for the right use case:

• You want app-coupled forms? Get a product that’s tightly coupled to workflow solutions. I obviously have a favorite, but this blog is not a promotional vehicle for Nintex; suffice to say that decent workflow companies offer you form options — look at them. Your app isn’t about workflow? Consider Visual Studio. Visual Studio LightSwitch, Access, etc.
• You want structured documents? Every Word and Excel file can be a structured document. So can PDF files.
• Data UI? There are a lot of options for that, too. Pick one you like. Again, I obviously have one I like, but your preferences may and will vary.

Yes, I know I mentioned four use cases at the beginning of this post, but I really hope you’ll abandon Standalone Application forms — those are just nuts.

You Asked For the Cloud App Model. Really. You Did.

The first time I ever met Joel Oleson, I was SharePoint team’s first Technical Product Manager, and he was working for Microsoft’s IT division. I went to them trying to get them to allow custom Web Parts on the SharePoint 2003 servers they used to provide team sites to all of Microsoft worldwide.

His response (and his boss’)? “No. We have no way of knowing whether a custom Web Part is poorly written and could crash our servers.”

When I was trying to advocate building on SharePoint to “regular” Web developers, their usual reactions went something like “Nice portal. How can I show my web site inside of it?” or “What? To develop for this thing you want me to bolt on components and modify its behavior?”

When did research with customers to see if they’d make use of a public Web Part gallery, a near-universal response was: “Are you going to vet what’s in there? If not, how will we know it’s not malicious?”

SharePoint still became a success, but extending SharePoint became a specialized area of knowledge, and the goal was (usually) controlling SharePoint, not contributing to it. Solutions were built, but they never really became a self-service thing.

Fast forward to 2013.

There’s now a means to (a) surface web content you created *any way you want, with any tool you want* inside of SharePoint, (b) a way to pass context, identity, and requests back and forth, and (c) a way to display apps in a curated catalog for self-service purposes.

It’s what you wanted.

It’s not perfect. Some things need to be finished. Some things really ought to be redone. But it’s still the right approach to take.

Office 365: All In, One Week In

I’ve been an Office 365 customer for a week now. I really like it.

Now, of course I’ve been working with Office 365 for a long time — longer than most people. But a week and a half ago was when I made it personal, and completed the changeover of mikefitz.com from Google Apps to Office 365.

Yep — mikefitz.com.  One of the benefits of being around for a long time is having had the option to get first choice on domain names.  And as such, if you want to email me personally as opposed to via Nintex, I’m reachable at mikefitz@mikefitz.com.

Admittedly, I’ve started with mail, and Exchange is great.  At $4 per month per user for Exchange-only support, I’m hard-pressed to find reasons not to do it.  No ads!  ActiveSync for mail, calendars, contacts, tasks, and notes — with multiple mobile devices!  IMAP (when needed) with real folders instead of labels-that-kind-of-behave-like-folders.

I don’t yet have a need for Lync on a personal level, so I haven’t done that.  I have, however, started adding apps to SharePoint Online sites to see what I can make use of.  I’ll investigate putting files in document libraries, but SkyDrive Pro is a pale shadow of SkyDrive, and DropBox does already does such a good job.  Still, if I can pay fewer cloud providers for storage, the move would be worth it.

SharePoint Online will remain a non-public thing, however.  I thought about activating the public site and using it for blogging, but then I remembered just how limiting SharePoint’s blogging capabilities are.  I’ll stick with WordPress and just redirect http://www.mikefitz.com to mikefitzmaurice.wordpress.com for the foreseeable future.  Pity.  I’d like to be more “all in”.

Still, this is good. I’ve known why companies have flocked to Office 365 for Exchange first, but now I feel it too.

Crowdsourcing’s Critical Connundrum

You can read more about the phenomenon here, but the basic gist is that there are people out there who have deliberately given things low-score reviews, even when they actually loved the product, app, etc., that they’re reviewing (and they’d say as much in the body text of their reviews).

Why? They wanted you to read their review. They want their reviews to be rated as “most helpful”, and there’s a higher chance of you looking at a lone “1” when most people award an app/product a “5”.  Their reputation score mattered more to them than the reviews they were writing.

Individual goals trump group goals more often than not.

I remember an attempt at Microsoft Consulting Services several years ago to build a website of best practices, technical advice, etc. The plan at the time was to have consultants rewarded for the number of posts they made. What happened? A few of my then-cohorts tried to game the system and submitted article-after-article of near-useless, obvious, already-covered-in-product-documentation stuff.

Same phenomenon: the individual goal of meeting metrics trumped the group goal of building a body of reusable knowledge.

There are many cases of perverse incentives. The most extreme one I’ve heard of is the Cobra Effect. A less dangerous one involved paying developers for every bug they fixed (after a while, they’d ignore code quality just so they could find/fix bugs more easily).

What can be done?  I can think of three options:

1. Make the game more elaborate by adding more rules. Think through the possible perverse incentives. More rules can make participation less attractive, and if so, the reward had better be worth it.
2. Make the payoff so low that the incentive to misbehave just isn’t present. Of course, that may result in lower levels of participation.
3. Alternatively, don’t crowdsource.  

I’m not a curmudgeon when it comes to social computing, in SharePoint, in Yammer, or anywhere else, but I do believe in caution.  Too many people hype “social” to death.  “Social” is useful, but it’s not magic.  If you treat it as such, you might find that sometimes it’s actually black magic.

Nintex Live: What It Is, Why It Was Created, and How It Works

We have a new product on the way called Nintex Live.  I did a few webcasts about it for Nintex partners a few weeks ago, and I demoed it at the Nintex booth at the SharePoint Technical Conference in San Francisco two weeks ago.  We’re planning to put it into beta late next month, and release it well before the middle of 2011.

If you look at what we have on our website you can see some preliminary content that’s been crafted.  It’s fine.  But I thought I’d talk about it a bit more conversationally…

What is Nintex Live?

“Cloud-hosted ‘air support’ for SharePoint workflows” is my current shorthand way to describe it, although that’s not perfectly on-message.  You can choose any or all of the following as well:

• – A cloud service hosted in Windows Azure that provides value-added services to Nintex workflows running in SharePoint.
• – A way to add new activities/actions to one’s workflow toolbox without installing any extra code on SharePoint servers.
• – A way to make virtually any web service “out there” look and behave like a workflow action.
• – A way to present a catalog of available actions to workflow designers – all of which have been sanctioned by IT.
• – A way to run a workflow that has been created/published in a remote SharePoint farm.
• – A way to publish a SharePoint workflow and allow it to be remotely invoked by a different workflow running in a remote SharePoint farm.
• – A way to make use of many of those data and calculation services published to Windows Azure Marketplace from inside SharePoint workflows.
• – A way to do all of the above very quickly, and very, very easily.

How You’d Use Nintex Live

Here’s how you’d use it from within Nintex Workflow 2010:

From inside of the normal workflow design environment, you’d click the ribbon bar button marked “Catalog”.  In the image below, it’s the button near the upper-right, next to the “Help” button.

If you click that, you get access to a catalog of workflow actions you can add to the design toolbox on the left side of the screen.  The catalog, at the moment, looks like this:

Choose the actions you want, click “OK” and they’ll show up in your toolbox a few moments after that.  Use them in your workflows like you would a local action.  When the workflows run, they’ll call out to the cloud to get the data – and/or perform the instructions – that you’ve requested.

There will be a method for IT to pre-filter which actions show up in the catalog for governance purposes.

What Nintex Live Does Behind the Scenes

If using Nintex Live seems easy, then we did our job.  What’s going on behind the scenes is actually pretty involved, but virtually none of it happens inside SharePoint itself.  We go to a great deal of trouble to avoid adding extra code to any SharePoint environment, and this is no exception to that rule.    We’re communicating with a service we have running in Windows Azure, in several ways, actually:

• – We query its catalog of available services – filtered in accordance with IT-supplied instructions – to present to workflow designers a list of available cloud-brokered workflow actions.
• – We even provide UI instructions to the SharePoint-located Nintex Workflow designer so it can construct the design-time UI out of metadata.  No code is sent to the SharePoint environment at all.
• – We listen to requests made by the SharePoint workflow over Windows Communication Foundation, and respond the same way.
• – We transform the request into the format required by each individual web services or remote workflow, invoke it accordingly, transform the results into a format consistent with a workflow activity’s results, and pass it back to the original calling workflow.  We handle all retry, warning, and error logic in a service-specific way.  If we have to poll for results, we do that.  If we need to wait for and handle a raised event, we do that instead, etc.

What Kind of Cloud Services Are Available?

We’ve already created wrappers for several cloud-hosted services, and we’ll be creating more on an ongoing basis.  Some are SOAP-based, some are Restful, others are, well, any of a number of things. 

So far, in anticipation of next month’s beta, we’ve exposed things like:

• – Services from Bing that check news stories, look up flight statuses, translate text, etc.
• – Services from StrikeIron that handle IP address lookups, check “Do Not Call” registries, etc.
• – Services from social media like Twitter and Facebook for posting status updates, searching for content, etc.
• – Services we created ourselves for reaching out to remote SharePoint sites to get/put content from/into lists and libraries.

It’s Not Just About Connecting/Consuming – It’s Also About Contributing

We have no intention of being the only people who can register services with Nintex Live for easy use within SharePoint workflows.  We’re publishing the API for creating service wrappers for custom Web services, for one thing, but that’s not the fun part.

The fun part is that you’ll be able to publish a Nintex Workflow to Nintex Live, at which point it will be available as a remote workflow (with inputs and outputs) that can be executed by other workflows in other locations.  Effectively, you can turn any workflow into a cloud-brokered service.

And any service publisher can decide who can/cannot use their services.  They can also see who’s using their services and how much.

Why Did We Use Windows Azure?

That part’s actually easy.  Everything else would have been painful.  Queuing?  It’s in there.  Scaling?  We can scale up via multiple threads and/or multiple instances if need be.  We don’t want to operate our own data centers.  We don’t even really want to maintain the OS and the application platform on hosted machines.  Windows Azure let us just write the app, deploy it, and use it. 

What’s more, Nintex Live isn’t a product – it’s an investment.  We’ll build forward from this to do a lot more than act as an action server to SharePoint workflows.  But first thing’s first.  More to follow as it’s ready…

Will SharePoint Server 2010 Put (fill in any given ISV here) Out Of Business? Nothing’s Impossible, But Probably Not.

Let’s get the easy part out of the way, the specific case of Nintex…

• Microsoft Office SharePoint Server 2007 shipped in November 2006.  Work on what we now call Microsoft SharePoint Server 2010 began months before that date.  I didn’t leave Microsoft until the end of May 2008. 
• Make no mistake: the day I left Microsoft, I put up a “Chinese wall” around part of my own head, and I continue to regard my ex-employee NDA as a sacred trust.  But ask yourself:  would Fitz join a company whose products would be rendered obsolete by what he knew was being planned for “Office 14”?  (Hint: no.)

And now let’s address the general issue, which applies to many, many ISVs…

• Microsoft develops software in three-year cycles.  Not every group at Microsoft follows this rule as closely, but the Office group (which develops all SharePoint technology) certainly does.  It’s for several reasons, the more interesting of which are:
• It appears to be the sweet spot; wait longer and the product gets stale, don’t wait enough and people are driven crazy with upgrade chores.
• It times nicely to Software Assurance (SA) agreements, which are signed for three-year cycles.  SA is essentially upgrade insurance.  Pay a certain amount of money over a three-year period and you get any new releases that come out during that time.
• There’s only so much that can be done by a finite number of people in three years.  You can’t increase the number of people without the coordination costs going through the roof.  That leaves limiting the feature set.
• To add to the above point, SharePoint technology has so many interactions with so many other Microsoft products – all of which usually ship at the same time – that they’re extra constrained by how much they can accomplish.  The test matrix alone is staggering, and at a point much sooner than most people think, testability determines whether something is kept or cut (or, very rarely, added).

The above argument pretty much ensures that the next version of anything you buy will be nicer, better, probably (in this case, I suspect definitely) worth the money and time spent upgrading, but it won’t be the release to end all releases.

There will be a gap between what you really want and what’s in the box.

Toward this point, Microsoft (at least the product teams in Redmond) all but depends on the partner ecosystem to plug feature gaps or create specific productized solutions.  Systematic procedures and practices are in place to help ISVs do exactly this.

In fact, when faced with enough resources to either add a user-facing feature or improve the platform so ISV products and custom development efforts can build such a feature, the second approach usually wins.  Not always, but most of the time.  Here’s why:

• It’s a bigger bang for the buck.  If they enhance the platform, many solutions can be offered that leverage the new functionality.  From different vendors.  Taking different approaches.  One of which will probably address your needs.
• Many people can build features or solutions.  Only Microsoft can build platform enhancements.  If ISVs attempt to do that, they’re basically hacking the back-end product – not the safest option in the world.

So, what makes for a decent ISV versus a not-so-decent one?  One topic at at a time — give me about 24 hours or fewer to post about that.

Visio 2010 Can Design Workflows. Good.

Apparently, the technical preview copies of the Office 2010 client apps don’t involve a nondisclosure agreement.  As such, blogging has commenced in earnest about the fact that Visio 2010 will have workflow design capabilities.  Wictor Wilén has a pretty good post on the subject, actually.

We’ve gotten a couple of inquiries about this already.  Actually, we get asked about what we’re doing for 2010 all the time, but these posts spurred two new questions:

• Does this mean I’m not going to need/want any third-party workflow tools anymore?
• This still means I’ll need to work with three products (Visio, SharePoint Designer, and SharePoint Server) to design, deploy, and use a workflow, won’t I?

These answers are easy, actually:

• For the most part, no.
• Yes.

Now, before I elaborate, let me reiterate what I said in my previous post; if there’s an early adopter program, anyone in it can’t talk about it. If I have any inside info, I’m not going to disclose it; if I don’t, I have nothing to disclose.  That having been said, I’ve frolicked in the SharePoint playground for a decade (if you count the prerelease Tahoe stuff) and I’m far from clueless…

The Visio 2010 stuff looks nice – really nice, in fact.  But yes, it looks like you’ll design workflows in Visio, transfer them to SharePoint Designer to deploy them, and actually use them within SharePoint itself.  At that point, three things come to mind:

• The platform is improving, probably by a lot.  This would bode well for anyone leveraging SharePoint’s workflow investments, including Nintex.  (It might give pause to companies that seek to replace SharePoint’s workflow technology with their own alternative products, though.)
• The design-and-deploy story looks like it will continue to rely on client-side tools.
• Unless a lot of people start buying a lot of new copies of Visio, this scenario will be fine for some, but by no means will it suit everyone.

Selfishly-speaking, all of these things are good for Nintex.  We want SharePoint’s native workflow infrastructure to get better; whatever they’ve done to accommodate Visio should help us as well.  We like the idea of Visio offering an offline design experience; heck, if it outputs standard XOML, we may well try to import Visio workflows ourselves (no promises). 

And as nice as this scenario appears, it’s far from the “workflow for everyone” ethos we espouse.  We put visual workflow design and deployment right into the SharePoint UI.  It’s there at your fingertips whether you’re a professional process-mongers or a casual user. 

And that’s just the design environment side of the equation.  I suspect we’ll learn nothing about what’s happening with actions/activities, logging/tracking/reporting/managing, and support for complex logic until the SharePoint Conference in October.

But a rising tide lifts all boats.  And the tide indeed appears to be rising.

Oh, The Perils/Joys of Limited Information

Trickles of information are coming in throughout the blogosphere on Office 2010, SharePoint Server 2010, etc.  I thought I’d add a bit of perspective from my days on the SharePoint team…

For the last three releases of SharePoint technology, there were early adopter programs.  In fact, for independent software vendors (ISVs), there were extra-early adopter programs so they could sort through, adapt, and enhance their products (or even create new ones) based on what was coming down the pike.  The thing was, any company involved had to sign a non-disclosure agreement (NDA) that precluded talking about, well, anything, even to people in other NDA programs.

If one were to assume that such a program is in effect for SharePoint Server 2010, et. al., the people who know the most are the people who can/will say the least.  You can, to a certain extent, identify people who will be very likely be thought leaders after all is revealed at the October SharePoint Conference, because right now, they’re pretty much keeping their mouths shut and their blogs silent.

This isn’t to say that speculation isn’t running rampant.  And there are now four sources of official information on what’s coming up that are public:

• Technical preview copies of the Office 2010 client applications
• Updates to the Protocol documentation created and published a few weeks ago
• Posted information at http://sharepoint.microsoft.com/2010/Sneak_Peek/Pages/default.aspx 
• Two sessions presented at the Worldwide Partner Conference, one by Arpan Shah from the SharePoint team and one by the Visio team

You can get a reasonable amount of information from these sources, but it pales in comparison to what isn’t being said.  Some diligent souls will do their best to sort through all of this, and I’m sure they’re welcome to try.  You can spot the good ones by the fact that they’ll stick to explaining what’s been revealed rather than speculating as to what hasn’t.

I’ll post some follow-ups on this topic presently. It’s kind of near and dear to my heart these days…