I've used Time Machine for years with a cheap HD hanging off an old Airport Extreme, until today, incidentally.
MacOS had started warning that this approach won't be supported in the future. After upgrading to Tahoe, Time Machine kept saying backup failed, no matter what I did, despite the fact it should still work. Oh well, I'll just delete the old backup and create a new one.
I delete the old backup, click "Add Backup Disk...", select the backup disk, and get blocked with "[Drive] can only be used if it contains existing Time Machine backups for this Mac." It did! You broke them!
UGH.
I thought I'd get another year out of it. Apple in their wisdom has decided otherwise. Now I have no historical or ongoing backups.
Arq Backup works great on Mac. It has a lot of smart features like only backing up on certain networks, only backing up when external power is connected, etc. You can backup either locally or remote (encrypted then uploaded to your preferred cloud provider, I used BackBlaze B2).
If you prefer free and open source, you can try Vorta (based on Borg Backup which I can also vouch for).
So "push" and "pull" as English verbs are basically opposite; and he's describing them as opposites in the previous post. But in this post he describes "push" this way:
> We are taught to do “discovery” to find their “pain points” and “problems.” So we waterboard potential customers with a series of questions to try to understand their current state... then try to surface their problems + pain points
And PULL this way:
> What are you trying to accomplish right now, or this quarter? Why this project now, vs. all the others you could prioritize? What options have you considered or tried, and what do you feel like is lacking with your existing options?
I don't mean to be rude but this idea that there's some decisive, authoritative data vs. sketchy anecdotal claims kind of drives me up the wall.
What data would or could exist in this case beyond the hundreds of calls the author is apparently basing their observations on? That seems like a reasonable qualitative data set to me.
On the other hand, what you're asking for doesn't make much sense. Any push/pull strategy difference is going to change who takes a call in the first place. You're not doing a RCT on a random sampling of the population.
The point is simply that you're going to have a better time doing sales if your supply matches some pre-existing demand. You don't need a quantitative study to understand why that may well be the case.
It's the same reason that, despite being bombarded with advertisements, we don't all go out and buy 16 meals a day or 10 cars a year simply because someone tried to sell those things to us. We act when we have a need, and founders need to understand that as a physical reality when trying to sell their products.
Your comment hits on a broader tension I see a lot, not just here but in business strategy in general. It's the divide between compelling, experience-based narratives and empirical evidence. I think both are essential.
The author has presented a fantastic and intuitive narrative with the "BUYER-PULL" model. Your analogy is spot-on: you can't sell 16 meals a day to someone who only needs three. The qualitative insight is powerful.
My request for data comes from the next step. How do we know this narrative is not just a "just-so story"? How much does this effect matter on the margin? In the complex world of B2B sales, where needs aren't always as clear as hunger, can "push" tactics sometimes be effective at helping a buyer crystallize a latent need?
Asking for metrics like close rates isn't meant to demand an impossible standard of scientific proof. Instead, it's an attempt to test the boundaries of this framework and understand its real-world impact. Great insights often come from quantifying the effects of a powerful story.
Fellow OCD-ish charge watcher here. Has worked great for my aging iPhone.
What grinds my gears though is the AirPods. I have AirPods Pro that I want to last a long time, but out of the case the earbuds are always 'on' and drain battery relatively quickly (much faster than a phone left idle); put them in their case and they're almost always* charged to 100%. I want to be able to leave them out, off, and disconnected. I almost never need 100% battery in my day-to-day use and there's no replacing the batteries in them once they're worn out.
An 80% max charge limit would be great.
*They do offer 80% overnight charge protection, but that's irrelevant as I don't keep them plugged in overnight
A decade ago, in an act of extreme futility, I wrote a book about HTML5. I did the mailing list archaeological dig to discover the logic behind these and other new (at the time) elements. There really wasn’t any. The spec editor just made them up on a whim with very eccentric definitions. I found that very frustrating as I saw it as inflicting a whole array of meaningless choices on front end folks for years to come. A decade later, and folks are still earnestly trying to divine the wisdom of the spec. No need — there isn’t any. There’s no there there. I don’t blame the author for trying, but I do blame the spec author for a very silly rabbit hole that people are still falling down to this day.
The ill-fated XHTML 2.0 was where the academics with actual interest in the semantic meanings of tags got too busy trying to cardinalize their semantic meanings. My understanding was that HTML5 "imported" some of the tag names but never had an interest in the intended semantic meanings as that was part of the schism that killed XHTML 2.0 and was something HTML5 wanted to avoid entirely for pragmatic reasons.
Under that understanding I think you can probably still find interesting semantic versions of these tags in the XHTML 2.0 mailing lists and schism discussions. They aren't relevant to HTML's present, but might be interesting for someone truly curious about the path not taken in semantic HTML (the path unlikely at this point to ever be taken).
I was curious so I compared the list of element tags between HTML 4.0 and XHTML 2.0, excluding the XForms module. Excluding XForms tags from XHTML 2.0, the former has 91 tags, reduced to 67 in the latter.
AFAICT, XHTML 2.0 reorganized tags into modules, yes, but didn't actually try to expand the set of semantic tags, except for XForms--the XForms module looks really complex. And those module groupings were more concerned with functionality, not content semantics, per se.
As far as I recall, that "final" draft of the XHTML 2.0 that W3 posted is "post-schism" just to get something out to compete with the growing momentum of HTML5 and kick the semantic can down the road again to XHTML 3.0 (after most of the damage of the schism was already done). I recall early XHTML 2 drafts had at least article, aside, section, hgroup, and others. I don't know where you would track down such drafts other than combing ancient mailing list archives.
Section and article makes sense as "parts of a book". However, unlike HTML, article is always hierarchy bellow section, it is actually bellow paragraphs. This schema is common in legal texts in many languages, I don't know if this is the case in EUA.
The hgroup elements also seems to be related to this.
My reasoning has always been that an article is a separable entity, which can do without the given context. (E.g., you can share it, or you can present multiple of them in varying order.) So a document may have sections, which may include articles, which in turn include sections, like the table of contents, a section of images, etc. So there's no distinctive hierarchy to them, as each may contain the other. (Mind that this is somewhat different from the use of articles in legal documents, which are integral elements of that document and lose meaning, if provided out of context.)
While any such interpretation is somewhat funny in the context of the parent comment, it may still turn out useful. E.g., if we were to scrape any content from an existing site in order to reintegrate it for a relaunch or a similar purpose.
And, as we're at it, a div is really just a technical means for applying something to a group of elements (e.g., in it's a original use, an attribute for centered text presentation), think of it as blocks in programming. Nothing semantic to see here, keep calm and carry on…
BTW, thanks for mentioning the hgroup, which is often overlooked, but really makes sense, when combining headings and subheadings, which are to be understood as a single item (like the head of an article, yes, an article in the common sense).
The actual specification of article and section elements in HTML is pretty much what you said.
My issue with them is not with their roles, but with their names. And, from the article and from OP, it seems I'm not the only one. I think "region" as it is used by WAI-ARIA would be a better name. Also something like "contentinfo" instead of "footer". And "complementary" instead of "aside"...
> E.g., if we were to scrape any content from an existing site in order to reintegrate it for a relaunch or a similar purpose.
The spec call this "outline".
Related to divs. I find ironic that making pages with tables were frowned upon 20 years ago, yet it is hot again now, but we are calling them "grids".
They say, the lack of usage of hgroups is due the lack of support by screen readers. Another common use case is <h1>Chapter 1</h1><h2>Foobar</h2>.
Regarding the table irony, see also the common use of table, table-row, and table-cell display styles for anything but actual tables. ("If I'm using divs, it's fine!") :-)
(Tables should even be more accessible, since there is <th>, both in <thead> and with `scope="row"` for table rows.)
Something, I've been guilty of (sometimes) for emulating hgroup: <h1>Heading<br /><small>Subhead</small></h1>.
In both cases article means something like "an atom of content". In legalese each statement is a separate article, in other context an entire book can be an article.
Heh, that's a little surprising. I never paid too much attention to the HTML5 element bikeshedding; I always assumed it was (like html) cribbed from sgml/docbook - but simplified (rather than randomly dumbed down).
So normally I'd probably go look at something like:
However - tfa was a lot more interesting and pragmatic - giving good advice on accessibility ; something that is actually worthwhile and not just silly bikeshedding...
Yeah, in this case, from memory, the spec author had a list of class names from a scraped HTML data set. He looked at the most common classes — nav, header, footer, and so on — and declared they should be made native elements.
Which would have been fine, except even the most obvious ones (header, footer) were given very idiosyncratic definitions, and others (article, section, aside) were seemingly thrown in at random.
This led to absurd examples where, as is still in the spec, a blog comment is an <article> and the comment's header is a <footer>. This of course undermined the original premise -- that these elements were just 'paving the cowpaths' of how people were authoring HTML, but the spec author would have none of it and shipped them all the same. And here we are. :)
This has been a thought that has been kind of recurring for me the last few weeks.
I think the problem of bad architectural decisions has been understated, possibly since the dawn of computing.
An example of greatness is HTTP and SMTP. I'd argue most cases don't even need HTTP/2 or HTTP/3 -- getting rid of all the tracking/bloatware on the modern internet would deliver more value for the end-customer but that's not the direction we're going in. The industry has boomerang'd back to nearly static sites (I think there was progress made, IMO SSR is a local maximum), so honestly HTTP/1 is often good enough.
An example of sadness might be Bluetooth. Every time I sit down to look at some docs that involve it (mobile, otherwise) I am horrified anew.
Bad standards basically set the entire industry back person-decades.
> (Of course, we don't do Shape Up in exactly the way described in the book: rather than cargo-culting, we've tailored the process to fit our business, which is a very different business to Basecamp. Happy to offer more detail if anyone is interested.)
Sure, would love to hear more about your use of Shape Up. What have you found that has worked in your context that goes beyond the initial framework, for example? :)
- As I mentioned, our business is very different to Basecamp's. We're a technology driven MR and insights consultancy that is increasingly platform and product focussed. As such we have four or five different customer/stakeholder groups, each with their own requirements. Our betting table is therefore larger, and includes representatives from each of these groups, as well as our product managers, and some technical representatives. This makes the meeting tougher to wrangle but does give everyone a voice. Like Basecamp, the CEO and I have final say over what the teams actually work on, but we've only overridden a betting table decision once.
- Our pitches include an ROI estimation. It's not particularly detailed, and we originally used something like t-shirt sizing. We now just give an estimated range. This helps us to have a more dispassionate discussion about which work to prioritise.
- We are about to implement a change to the way we shape pitches, to break this up into two phases which run across two cycles. The first phase will focus on clarity about the problem we're trying to solve, the value of solving it, and our investment appetite. We'll then make decisions about which pitches we want to take to the second phase, which is a kind of extended validation, and will be where more research is carried out, and proposed solutions are roughed out. This should help us more effectively manage workload around pitch preparation, and ensure pitches are ready for teams to start work on at the beginning of cycles where they are prioritised.
- We have regular check-ins with business stakeholders throughout each project, and they are involved in decision-making around any changes of direction or scope, or trade-offs that need to be made.
- We have strong guidance in place for the teams around where they should be throughout the cycle: e.g., when they need to stop adding functionality, and focus on delivery; derisking each project, which should happen early, when UX testing should occur, etc.
- We do sometimes reprioritise our strategic roadmap to ensure that we are adding necessary functionality to our platform in order to bid for and service high value client projects; such projects still get oversight from the betting table and could, at least in theory, be deprioritised if there were serious objections.
It's not all been plain sailing though. For example, we still struggle to appropriately shape small batch projects, and getting people outside of tech onboard with creating pitches is an uphill battle, though one we are slowly winning.
That's really fascinating, thanks so much! I like the sound of your two cycle pitch approach -- kind of putting 'measure twice, cut once' into practice. And I admire your ability to wrangle a larger betting table & bring others into the pitching process!
Unfortunately that scenario only works if there’s a ‘fair’ long/short game beneath the fraud, but the fraud is such that that is not the case:
Remember Folks: Don't short Tether, once the exchange leaks your position to their buddies, Bitfinex shareholders will organize to liquidate you by working with their wash trading bots.
My understanding was that Boeing wanted to prevent Airbus from winning contracts and so pushed the schedule hard. That's the sales and marketing division talking isn't it?
MacOS had started warning that this approach won't be supported in the future. After upgrading to Tahoe, Time Machine kept saying backup failed, no matter what I did, despite the fact it should still work. Oh well, I'll just delete the old backup and create a new one.
I delete the old backup, click "Add Backup Disk...", select the backup disk, and get blocked with "[Drive] can only be used if it contains existing Time Machine backups for this Mac." It did! You broke them!
UGH.
I thought I'd get another year out of it. Apple in their wisdom has decided otherwise. Now I have no historical or ongoing backups.
Any recs on what to use instead?
reply