I notice that Roam has been apologizing this week for some loss of data from their servers.
Understandable, and that is why I avoid these web-based subscription services.
3 Likes
Understandable, yes, for a service that’s very clearly still in development. I do think that their promotion via enthusiasm has contributed - they have tens of thousands of users on a service that’s not finished, and a significant proportion of the users seem to have dived in deep. Cultivating that before you know you can meet the most basic requirement (don’t lose the data) seems at best naive.
The data loss a few days ago won’t do anything good for Roam’s reputation as a grown-up service.
I’m still enjoying playing with it - it’s a very nice way to jot notes - but I don’t trust it.
Just checked and they are posting this notice:
There is nothing on their home page explaining this is a beta product. Users beware.
1 Like
Democratically can-do enthusiasm is an undesirable quality in software work.
The Linkedin profile of the operation which produced the Iowa caucus app seems to suggest a highish level of it:
1 Like
A few observations:
-
I think we’re straying a bit from the topic here.
-
There’s nothing wrong with being a programmer who has worked at Starbucks or Regus. And there’s nothing terribly wrong with getting code that supports a campaign from the campaign’s supporters. Obama’s 2008 victory was fueled in considerable measure by just such an app. In my experience, campaigns rely too heavily on established consultants and established technologies.
-
The underlying problem was the failure of the fallback plan. That failure may well have been engineered by Republican operatives coordinating a scheme on Reddit.
-
The remaining failure is that the caucus rules are complex and, in the nature of things, caucuses at the precinct level are run by people who mostly haven’t done this before. If they do have experience, it was using different rules, and it was four years ago. Often, they’re doing it with a mixture of acquaintances they see every day and a bunch of strangers, campaign officials, and reporters who are enthusiastic and determined.
5 Likes
nothing wrong with being …
Absolutely not !
But entrusting democracy to understaffed projects is not responsible.
Underqualified enthusiasm serves marketing better than engineering.
(as you say – off topic)
1 Like
Tying this back to Roam and the question of naive developers. Another problem manifest in the sometimes fatal effects of the new Computerized Medical Records is top down designs that do not involve the thinking patterns, actual work conditions, etc of the actual users. Roam developers have been very actively trying to learn about their users and usage in early stages. I would much rather have clumsy software or even “traps” than omissions of user problems leading to death or permanent injury of patients. Example. One early program required multiple pharmacy checks before shipping meds to the ward, no allowance was made for emergency transfers of babies sometimes with “defective” histories so drugs could not be delivered in time to save lives.
A good point. For me, the naivety is less in encouraging the breadth of use than in not being explicit about the state of the service and the risks (I know users have to take some responsibility too) nor in making sure the service was robust enough to handle the situation.
What we have now is basically a sandpit, which is fine - but the devs need to says so and keep saying so. I don’t want to be too hard on them because what they’re doing is potentially useful and should be encouraged, but they do need I think to demonstrate a bit more awareness
Disclaimer - I’ve only looked at the app, not used it.
I’m responding to the meta discussion. A number of points are well made. But, as someone who has spent their life at the interface of tech folk and wider non-tech (non-coding) humans, I often see a lot of hubristic assumptions about ginuea-pig users; the latter are not the same as knowing beta- (or even alpha-) testers.
I happily voluntarily beta-test here and take the (surprisingly few!) bad outcomes that can occur. But the ‘contract’ is open and knowing. By comparison, a ‘web-app’ using my interest in the promised outcome as an unpaid [sic] tester to figure out what the app should be is, IMO, abusive of the unwitting user and symptomatic of the low esteem shown to users of of a web-biz=>scale=>riches business model.
A sadness, over the years, is watching a lazy desire by users to mould good specialist Mac apps, Tinderbox and others like it, to just-do-my-stuff bucket. IOW, being able to use a hammer in lieu of a screwdriver, drill, chisel, etc. Conversely, the true value of long-lived, deep and more complex apps is what they do well, rather than what they don’t. I’ve just spend 18 months, yes, 18 months, helping a a non-tech non-coding user import data from [someApp]. The problem was that [someApp] did a particular form of data capture really well but, in truth, sucked at all aspects of export. Just because Tinderbox can read data suddenly made Tinderbox the problem. Well, that took 6-9 months to explain (“But I just want to…”). The everything/everywhere/anytime aspect of the web has infantilised us all; thinking work takes thought.
If the word ‘lazy’, above, acts as a trigger it’s worth noting that larger teams (or ‘agile’ development) don’t necessarily produce the best outcomes; the best software I use daily comes from small teams or individuals. Interacting with real humans who actually make (code) software is a privilege and one I hope will continue. I’m also not a fan of subscription services - they don’t scale on the user side. My sadness is I now use (and thus pay towards) fewer software tools than of late as I can’t afford usurious monthly subscriptions for tools I appreciate but use infrequently. I’ve watched several iterations of software purchase cost models over the years and my hunch is a finite market for specialist tools will eventually yield a new (old?) and better model.
4 Likes
After clicking on the sign-up button, a subsequent dialog displays stating the Roam note-taking app is a beta product. Conor sent out a detailed email this morning (Feb 7) to all beta testers explaining the current situation regarding sync, among other things.
Perhaps there should be considered a difference between voluntary users who chose and also support the software (TBX) and the victim user who MUST use the software provided. The program’s design in the hand’s of yet a third party who controls choice and may specify goals that are not same as the user. It may be fake news but I read a manufacturer of oxycontin actually hired a firm to insert instructions to prescribe it (preferentially) into prescribing protocols for physicians on their office computers.
… and the message was (in brief)?
Short version:
“Server couldn’t handle a sudden spike in usage and dropped transactions with no notification (other than user experience. Cause of uptick was response to enthusiastic review
It’s never happened before, we’re very sorry, we’re making changes.”
I’m totally confused by this. The TBX file format in which Tinderbox document data is stored is a well-formed XML document. This means any user can access all the information and/or export it to some other format/system even if they have no access to the Tinderbox app.
So, the data isn’t trapped in a secret binary format. Meanwhile, who is being forced to use Tinderbox? Everyone with whom I’ve had any interaction at any depth is someone who has chosen to use the app, and the only other users with whom they interact are the wider Tinderbox user community—rather than co-workers.
This is simply not true of Tinderbox, and an undesired calumny upon Eastgate. The app is made by a known organisation—Eastgate Systems , Inc.—which also makes the one of the few (only?) non-Web-based hypertext tool, Storyspace. Tinderbox has been produced by the same coder since inception in 2001 and Storyspace for even longer.
I’ve been a personal user of Tinderbox since 2004 (and an (unpaid) volunteer community helper since not long after that. I have never [sic] seen evidence of some ‘third party’ exerting an influence unaligned to users’ needs. I’ve been a volunteer ‘wiki gardener’ of the original user wiki, then an admin/mod of the YaBB-based forum, and then of this one. I read every post (apart from users’ private DMs) and quite the converse to the suggestion above, I’ve seen a software developer ready to encompass users’ ideas—even when they diverge somewhat from the core concept of the app.
We really do seem to be wandering off into the weeds here, though I’m not sure why.
I sense we’re done on Roam for now. I’m going to leave the thread open for now but if it continues to wander off-topic, I’ll likely lock it as it is of little use to the user community coming here to find out about Tinderbox.
1 Like
As the OP, I’d be a little sad if we got to that point, because I do think that there’s some commonality in the purposes for which Roam and TB are used and therefore some room for interesting and perhaps useful discussion.
But if the conversation’s going to wander into the weeds, please by all means put it out of Its misery.
1 Like
Agree. I’d still like to know if there are integration possibilities on the horizon.
Is there a page on the Roam site documenting export formats, automation features, etc.? ISTM, that might be a useful benchmark reference, even if Roam is still at alpha/beta?) stage of maturity.
Roam imports and exports markdown and JSON – feature is available in the contextual menu for each page.
1 Like
Whatever there is is here and in demo videos - in other words, not much.
There’s no automation built-in, although people are writing (and publishing) their own
There’s a simple import/export to Markdown or json
1 Like
Tinderbox doesn’t have a 'built-in ’ JSON import. However, note Tinderbox has AppleScript (OSA) support, wouldn’t that be a quicker more robust means to read in JSON from Roam (or other sources)? Unless the JSON source is known to produce rock-solid code with appropriate escaping, etc., a script offers a more flexible route for dealing with variations in source quality. A built-in method would need a new build pushed anytime changes were needed.
I’m not overlooking that means someone writing the ‘ingest’ script, but at this point I’m just thinking of where/how ingest of Roam data might occur. As Roam is web-based, I presume all notes (pages) are essentially a discrete URI that can be called from Tinderbox using a a URL-type KA, a web link in text or even an RTF-only RTF autodetected link (currently the latter aren’t adopted as actual Tinderbox links, because… reasons).
[edited by MB to avoid confusion; correct if I’m mistaken]