Gathering Console messages for our support folks

Deep support issues sometimes raise questions we can’t ask you to answer, so we gather details directly from your Mac’s log files, System Information reports, and, on macOS Sierra and later, Console messages.  The first two take a few steps, but Console messages are a little harder to get at.  They give us a lot of information, though, and we sometimes need that extra bit of detail to figure out what’s happening behind the scenes.

Here’s how to gather your Console messages and help us help you:

  1. Click the Finder icon on your Dock.
  2. Go to the Go menu at the top of your screen and click the Utilities menu item.
  3. Double-click the Console icon.
  4. If the icon in the Activities button, next to the Now button, is tinted blue, click the button once so the tint is removed.
  5. Go to the Action menu at the top of your screen and click the All Messages menu item.
  6. If we’ve asked you to search for a particular phrase, click the Search field at the top right of the window, type the phrase, and press the Return key on your keyboard.
  7. Leave Console open, return to our application, and follow any steps to reproduce the situation you need help with.
  8. Return to Console, click one of the console messages, then go to the Edit menu at the top of your screen and click the Select All menu item.
  9. Go to the Edit menu at the top of your screen and click the Copy menu item.
  10. Click the body of a message to us, go to the Edit menu at the top of your screen, and click the Paste menu item.
Posted in General | Tagged | Leave a comment

Three CheckBook 2.6.1 fixes coming in hot!

Here’s what’s on the way in CheckBook 2.6.2, due later this week:

  • Scattered reports clued us in on a crash that can happen on OS X 10.10 Yosemite and macOS 10.11 El Capitan.  With a document open, try to create a new document or use Open Recent in the File menu to select another document and boom!  This crash is crushed.
  • A very helpful person sent us a screen recording demonstrating how to get the Debit button to stop working.  It came down to a tiny glitch in how our 64-bit code for creating a list of all previously entered To items.  This glitch is history.
  • Another kind soul showed us how CheckBook Pro might display Entries in a password-protected Account while waiting for a password to be entered.  Turns out we were a little too aggressive in trying to display actual data as a document first opens and missed a key step in validating our security model.  This bug is bashed.

If you need these fixes right away, send a message to support@splasm.com and we’ll get you a pre-release build.  In the meantime, tell us when you see anything out of the ordinary and we’ll pop open another can of bug spray!

Posted in CheckBook, Development | Leave a comment

Why the Mac App Store needs a waiting period before new reviews go live

Years ago, six, in fact, I wrote a detailed analysis of how Apple could improve the Mac App Store experience between users and developers.  You can read it all at http://www.splasmata.com/?p=1612.  One of the finer points in that analysis, and, perhaps, so diplomatically put that it didn’t hit home, was a simple, one-size-fits-all app rating and review system can’t work.  If you didn’t read reviews, and especially if your livelihood didn’t rely on them so you didn’t keep track of what happens when reviews come out in public, you might think folks will write a review to praise or criticize, then move along, continuing with an app or ditching it, and no one’s hurt.  Are you nodding in agreement?  Stop because nope.

So let’s put it this way:  some reviews are based in reality, some aren’t.  Some folks think about the consequences, some don’t.

Here’s the thing:  people write reviews for a number of reasons, from a variety of experience and technical expertise levels, in a multitude of physical, spiritual, emotional, and chemical states.  You can’t anticipate all of that.  Even folks who know how everything fits together to make an application work get things wrong when they’re dragging ass on three hours of sleep.  Like me.  On top of that, people aren’t always aware of the path a review will take through every other user’s eyeballs and into their consciousness, and few realize what a single negative review can do to a tiny company’s income.  And the icing on it all is computers are complicated to the point you don’t always get a clear picture of cause and effect.  That’s how popup ads telling you your Mac is hosed if you don’t install Ultra Mac Platinum Cleaner Pro Deluxe right this minute hit the mark.  So let’s put it this way:  some reviews are based in reality, some aren’t.  Some folks think about the consequences, some don’t.  

I’m reminded of the old adage of the three tests.  Before you say or do something, is it true?  Is it necessary?  Is it kind?  If it’s not true, don’t.  If it’s true but not necessary, don’t.  If it’s true and necessary, make it as kind as possible.  There’s a time and place to ignore this advice…but what about ratings and reviews?  Do we have to tell the truth in our reviews?  Should we only write them when necessary?  Are we obligated to write them as kindly as possible?

In a cosmic sense?  Nope.

Between you and me?  Pretty please?

We’re sure ratings and reviews are necessary.  They pretty much make it practical to find a product that competently performs a required task without requiring you to become an expert on every product in a given market.  A considerably poorer expert, too, I’d say, as in most cases, there’s no try before you buy in this world of ours.  Case in point:  the Mac App Store.  But trials are another suggestion I and a bunch of other folks
made six years ago.  Let’s get back to our topic:  the rating and review system on the Mac App Store.

Here’s a real world example of how a review system, in the hands of someone who’s identified an issue but doesn’t have enough information, becomes a terrible missile, unintentionally armed and fired, harming instead of helping.

 

Anyone with some marketing experience or a little common sense in the room?  You wanna come up and write on the chalkboard, so everyone can see, how this review is not doing anyone any favors?

First, the review’s title is written with passionate use of exclamation marks, so you know this is very important!  Second, it’s not just a 1 star review, it leads with “one star!“, so you know this is both very important and very bad!  Third, it continues with the word “warning“, which is never good and usually very bad.  Fourth, it gives readers – our users, I’ll add – the panicked news that the software is compromised by a parasite of some kind!

That’s all before you get to the actual star rating.  A single star tells some people the review is likely extreme, and therefore questionable.  They might skip it.  For other folks, though, 1 star says, “move on quickly, this product probably isn’t worth your time.

It’s a minor miracle if anyone gets past everything in that first line without bailing, but say they do.  They’ll find the review itself is a well-written explanation of the review title.  No exclamation marks, just the facts the way the person saw them.  And no matter what the situation, who they are, what their expertise level is, or whatever, the user has a right to write a review exactly like this.  That is not and never will be in question.

So what’s the question again?  We’re getting there.  Before we do, let’s pass this review through those three tests to see how it doesn’t work in anyone’s best interest.

To start, the entire reason for the review is false.  Our application has nothing to do with Advanced Mac Cleaner.  Nothing.  And it never will.  Maybe the user saw Advanced Mac Cleaner while using our application and associated the two.  Who knows?  It’s simply not true.  The user would know that if they asked us before posting the review.  But they didn’t, so we received the pointy end of their missile without any warning or opportunity to provide the truth.

You know, there’s a really important point here and we’re going to come back to it:  in this user’s defense, how could they know what they were writing wasn’t true?  It looked true to them.  Can’t get any truer than that, unless someone helps you out with truthier truth.  So let’s say they got past truth and moved on to necessity.  How’s this kind of review necessary?  Well, wouldn’t anyone with some conscience and empathy want to warn other folks away from a potential calamity?  I would.  That about covers necessity.

And what about kindness?  Again, I feel the need to, kindly, defend our users here.  Most of them aren’t technical.  They’re good at what they do and we’re good at what we do.  They wouldn’t expect us to get what they do right all the time, and we’d never expect them to get what we do right all the time.  At a guess, most have never visited the About page on our website, so they don’t realize we’re a tiny, three-person company.  They don’t know we’re Mac-only, so the Mac App Store is our largest distribution channel.  They don’t have the stats over the last six or seven years to show that a single negative review in front of thousands of users on the Mac App Store will cost us hundreds or thousands of dollars, putting our payroll in peril.  The web has transmogrified from a crazy universe of slightly hard to remember addresses and organized bookmarks to a few search engines and a plethora of single-serving apps, the Mac App Store among them, so many don’t know how to get in touch with us directly, don’t notice the support link on the Mac App Store.  For them, our Mac App Store product page is all there is, and posting a review there is all they can do.  It’s not a kind act, to say the least, but it’s just about impossible for a user to realize they’re acting unkindly.  They just don’t know any better.

Starting to feel like there are a lot of variables out there, isn’t it?  Long sigh.  There are.  And that’s part of the point.

Hold a developer’s feet to the fire if they’ve really messed up.  Heck of a shame if you’re barking up the wrong tree, though.

So, what’s the real question?

Folks are entitled to write what they will.  Apple lets them.  But those same people depend on accurate, factual ratings and reviews on the Mac App store to give them a clear picture of what a product can do and how a company stands behind it.  Likewise, developers depend on the Mac App Store as their largest distribution channel and need accurate, factual reviews to attract the audience they’re looking for.  If Apple wants happy users and happy developers, then, they need to figure out how to keep it real, so to speak.  In an ideal world, they’d even hold folks to all three tests:  truth, necessity, and kindness.  Let’s not go bananas, though, so we’ll stick to truth, for now.

There’s a disconnect between the user’s perception of the facts and the facts themselves, so in some, perhaps not many, but in some cases the test of truth is failed almost out of the gate.  So the real question is, how can Apple build into the Mac App Store a way to handle the user’s perception of the truth versus the truth itself?  How can Apple let users express themselves and provide value to other users while making sure reviews are based in fact before they’re released to the public and allowed to damage the developer?  And, lest I be perceived as biased, you bet I believe developers should be held accountable in the court of public opinion.  Hold a developer’s feet to the fire if they’ve really messed up.  Heck of a shame if you’re barking up the wrong tree, though.  Like, kids not getting Christmas or families not making mortgage payments kinda heck of a shame.  And that kinda shame is, very bluntly, bull.  Very personally, twins are coming into my life in January and daddy wants them taken care of.  Allan has a mortgage and kinda likes that house.  Randy’s practically a full-time dad, feeding eager minds with homeschooling every day.  We don’t charge an arm and a leg for our product because we want to be fair.  We’re just looking to keep it fair all around.

Now, what’re we to do?

If Apple wants to help prevent a single user’s perception of the truth from devaluing the review system, hurting other users and developers at the same time, how about allowing developers a chance to look over new reviews before they go live?  We called this a quarantine in my original post six years ago.  You read that right.  I suggested this six years ago.  Sent my suggestions to Apple and everything.  Six long years.  No movement.  But here’s how it works:  the reviews come in, the developer has 24 or 48 hours to respond to the reviewer through an anonymous communication system on the Mac App Store, and the reviewer must at least acknowledge the developer response before the review can go live.  How the developer and reviewer handle the dialogue in the meantime is completely up to them.  At the end of the quarantine period, the user may have done nothing, or changed their review, or even removed it.  If they received service and changed the review or removed it, they’re happy.  If they haven’t removed the review, it goes live and they’re happy.  There’s a much better chance the reviews that stay are accurate.  Users win all around.  The developer may grumble a bit if their effort failed to convey to the user the review is unmerited, either with facts or real service, but they always have the option of asking Apple to remove the review if it’s truly false.  Nothing is lost over the current system.  Much is gained.  Everyone’s happy.

So there you have it.  We’re raising the idea of a quarantine once more, in the hope that users will see our perspective and, if we’re lucky, someone at Apple will take notice.  Thanks for reading!

Posted in General | Leave a comment

Help for a few issues with CheckBook and CheckBook Pro 2.6

[Update:  The issues in this post are addressed in CheckBook and CheckBook Pro 2.6.1,  officially released on 10/30/2017.  Mac App Store users can update by visiting the Mac App Store and clicking the Updates button at the top of the window.  Splasm Store users can get the update by opening your copy of the application, going to the CheckBook or CheckBook Pro menu at the top left of your screen, and clicking the Check For Updates… menu item.]

If you installed CheckBook or CheckBook Pro 2.6 after their release early this week, you may have noticed a few things aren’t quite right:

  • Sorting by Next Entry Date in the Schedule section is unpredictable
  • Column layouts in Entry, Reconcile, and Schedule may not be saved
  • The last selected Entry may not be saved when you close and reopen the application
  • If you created or viewed the details of a transfer, a crash might occur as you close the document or quit the application.

We’ve got fixes in pre-release builds you can check out now, and should have the official builds out soon.

Before you download, be sure you download CheckBook only if you already have CheckBook, with a green pen in its icon, or CheckBook Pro only if you already have CheckBook Pro, with a blue pen in its icon.

 

CheckBook users (CheckBook has a green pen in its icon)

Download the pre-release build at http://splasm.com/special/checkbook/CheckBook%202.6.1b2.zip

You’ll likely find the download in your Downloads folder, available by clicking the Finder icon on your Dock, going to the Go menu, and clicking the Downloads menu item.  Double-click the file named CheckBook 2.6.1b1.zip and you’ll see the new build, with a similar file name and a real CheckBook icon.  You can go back and forth between this build and the official CheckBook 2.6 build you already have, but we recommend not using both at the same time.

 

CheckBook Pro users (CheckBook Pro has a blue pen in its icon)

Download the pre-release build at http://splasm.com/special/checkbook/CheckBook%20Pro%202.6.1b2.zip

You’ll likely find the download in your Downloads folder, available by clicking the Finder icon on your Dock, going to the Go menu, and clicking the Downloads menu item.  Double-click the file named CheckBook Pro 2.6.1b1.zip and you’ll see the new build, with a similar file name and a real CheckBook Pro icon.  You can go back and forth between this build and the official CheckBook Pro 2.6 build you already have, but we recommend not using both at the same time.

 

Thank you

We wish these issues hadn’t made it into the wild, but hope to have you all taken care of very soon.  If you need any help please get in touch at support@splasm.com.  Thanks to everyone for hanging in there!

Posted in CheckBook | Tagged | Leave a comment

How’s compatibility with macOS 10.13 High Sierra?

As autumn falls upon us and the yearly flood of Apple product updates washes over the masses, we return once again to macOS update season.  Christened “High Sierra”, macOS 10.13 brings relatively few user-facing changes but a plethora of new goodies under the hood.  A tweak here, an optimization there, and new frameworks all over the place usually add up to a bit of overtime for third-party developers but all seems rather mellow this year.  Nope, our applications won’t be dramatically affected by the coming of High Sierra.  Here’s a rundown:

Audiobook Builder 1.5.7

Nothing out of the ordinary in our tests, even with the new APFS disk format macOS 10.13 High Sierra may use for your SSD startup drive.

CheckBook and CheckBook Pro 2.5.15

Both applications appear to run well, but you might see a little smear or blur on the right edge of some buttons, which we’ll have fixed in 2.6, now in beta, and you won’t see the spinning progress wheels when saving a document or refreshing an Account Summary.  Word is Apple’s working on that.

Return Labels 1.0.2

Looking good, so far, except for a drawing glitch with focus rings when tabbing to or from some buttons.  We’ll get on that soon.

Send a message to support@splasm.com if you spot anything in your own tests.  We’re thankful for your time and appreciate all the feedback we can get!

Posted in Audiobook Builder, CheckBook, Development, General, Return Labels | Leave a comment

32 bits, 64 bits, whatever it takes…

A few worried looks have come our way lately, from folks wondering whether Audiobook Builder and CheckBook Pro will be ready before Apple requires all Mac App Store updates support 64-bit in June of 2018.  Don’t worry, friends.  Things are both simpler and more complicated than they seem.

Here’s Apple’s most recent statement:

At WWDC 2017, we announced new apps submitted to the Mac App Store must support 64-bit starting January 2018, and Mac app updates and existing apps must support 64-bit starting June 2018. If you distribute your apps outside the Mac App Store, we highly recommend distributing 64-bit binaries to make sure your users can continue to run your apps on future versions of macOS. macOS High Sierra will be the last macOS release to support 32-bit apps without compromise.

Boiled down, Apple will require all new Mac App Store applications include 64-bit support in January of 2018, and all Mac App Store updates include 64-bit support in June of 2018. 32-bit applications will continue to work as usual in macOS 10.13 High Sierra as well as whatever comes after, though Apple mentions the possibility of compromise.  We think that compromise will be minimal or unnoticeable for many applications.

Let’s compare this to what’s been happening on iOS and get a clearer picture:  for the last two years, iOS has warned that running a 32-bit app might impact performance.  In most cases, performance wasn’t affected and 32-bit apps kept trucking.  Still, this fall, iOS 11 will put the kibosh on 32-bit for good.  We expect the 32-bit party on macOS to end in about the same way. A couple of years of warnings with no real performance issues before something like macOS 10.15 in 2019 sends 32-bit to the history books.

It’s kind of a non-issue for the next two years.

So how does this play into our roadmap for Audiobook Builder and CheckBook Pro?

We tidied up a few things and, in addition to check printing, the latest pre-release build of CheckBook Pro 2.6 has that sweet, sweet 64-bit goodness.  When 2.6 is released you can grab the update and everything’s groovy.  Regular CheckBook users will get the 64-bit part sans check printing.

Audiobook Builder has a slightly more complicated path.  We’ll level with you:  It makes extensive use of QuickTime 7, which won’t survive macOS’s move to 64-bit-only, and that’s a major rub.  Our plan has always been to make Audiobook Builder 2.0 the point where we migrate from QuickTime 7 to something more future-proof.  The catch is that’ll mean a few months of re-engineering the “Builder” part of the application – and we won’t have the resources for that until both CheckBook Pro 2.6 and CheckBook for iOS are out.  We’re about to begin the yearly scramble to update all our applications for the next major macOS release, and we’ll have another scramble just like this one same time next year.  Some years the scramble is quick and painless, and some years not so much.  All of that means Audiobook Builder 2.0 has to be pushed out to mid to late 2018, at least.  Just remember 32-bit applications will continue to work until then.  You’ve got Apple’s word on that.

Questions or feedback for us?  Get in touch at support@splasm.com and we’ll get you taken care of!

Posted in Audiobook Builder, CheckBook, Development, General | Tagged | Leave a comment