Fab's AutoBackup 7 Pro - a must have tool for techs

That's how I read the site and the terms. You purchase for one year or three years, and after that's expired if you want additional time getting updates you buy the time-limited license time you want. @fabs can answer definitively, though.

The order should still be associated with the account you established at the outset.
That's how I read it too but wasn't sure.
 
@fabs,

Something occurred to me today that I hadn't really thought to ask before: Does Fabs AutoBackup gracefully handle interruptions, whether things like power going out or a user doing a premature cancel? And by that I mean if you start it again, can it pick up from where it left off?

It would be fine if it has to start from scratch, but it's possible that it could be progress logging and could pick up again mid-stream and I'm wondering which it does.
 
@fabs,

Something occurred to me today that I hadn't really thought to ask before: Does Fabs AutoBackup gracefully handle interruptions, whether things like power going out or a user doing a premature cancel? And by that I mean if you start it again, can it pick up from where it left off?

It would be fine if it has to start from scratch, but it's possible that it could be progress logging and could pick up again mid-stream and I'm wondering which it does.
In fact, it is a mix between both : if copy gets interrupted for some reason, next time you will start the same job with the same destination, while listing files to copy, it will compare them with the ones that are already in destination and will skip them if they are the same. Then it will resume copy as soon as this comparison is over.
 
@fabs

Thanks for the clarification. I had to interrupt Fabs yesterday and decided I'd start it again later just to see what it did. It became apparent after the initial processing was done that it was, effectively, picking up where it left off.

It's good to have this sort of information "on the record" from the developer.
 
@fabs,

This would likely best be discussed in detail outside this venue, but I wanted to let you know that Fabs Autobackup Pro, as currently constituted, is absolutely not screen reader accessible. I was about to recommend Home & Office on one of the blind tech groups, but when I did my quick and dirty testing with Fabs and NVDA, you not only cannot access any of the three main controls on the first page, but the screen reader seems to be interacting with what one typically sees after having activated the choice for backup (though I can't be sure of it because it's still hidden behind those three choices). It's the same when using Narrator as well.

I do not know how trivial, or complex, it might be to make Fabs Autobackup screen reader accessible, but its worth thinking about and, perhaps, pursuing over the long term.
 
@fabs,

This would likely best be discussed in detail outside this venue, but I wanted to let you know that Fabs Autobackup Pro, as currently constituted, is absolutely not screen reader accessible. I was about to recommend Home & Office on one of the blind tech groups, but when I did my quick and dirty testing with Fabs and NVDA, you not only cannot access any of the three main controls on the first page, but the screen reader seems to be interacting with what one typically sees after having activated the choice for backup (though I can't be sure of it because it's still hidden behind those three choices). It's the same when using Narrator as well.

I do not know how trivial, or complex, it might be to make Fabs Autobackup screen reader accessible, but its worth thinking about and, perhaps, pursuing over the long term.
I've no idea on how to do that either. The first thing I think about is the color scheme that may not be very screen reader friendly. Perhaps I could look at this in a first place
 
@fabs,

This really has nothing to do with color scheme as far as screen reader access goes, and, in fact, that would be entirely irrelevant to a blind user, as they can't see anything, literally.

It's a matter of coding the UI such that it follows the published standards (e.g., WCAG [for web accessibility]) for writing accessible UIs. I can't remember the name of the one for desktop applications at the moment, but I'll ask where someone would and actually mention those standards/conventions here after I have them.
 
@fabs,

This really has nothing to do with color scheme as far as screen reader access goes, and, in fact, that would be entirely irrelevant to a blind user, as they can't see anything, literally.
I know that blind persons cannot see colors, that's obvious.
I was thinking that screen readers probably needed some high contrast scheme so it could make the difference between text and other parts of the graphical interface. Anyway, this is definitely something I need to care about
 
@fabs,

No, that's really not how screen readers work. It's not an OCR process. You could have everything be black on black or white on white, completely inaccessible to vision, but if the coding is done to accessibility conventions, what's exposed to the screen reader is still there. Screen scraping, as was once done, has not been done in quite some time now because accessibility standards make it unnecessary. And once anyone starts coding with accessibility in mind from the outset, it's just really easy to make and keep things accessible. Retrofitting it is the nightmare, and even that's probably less nightmarish for a UI such as the one you have, as most of the controls are directly amenable to having things like labels, alt-text, etc., associated with them. I can't figure out what, exactly, the opening screen where you pick Backup/Restore/Transfer is, because although I can see it, and point and click on it, it's as if it's not even there for a screen reader. The screen reader is interacting with a window that's clearly active already that lies underneath that initial choice screen.

In any case, I do think this is a discussion better conducted privately, which I'm happy to do. I do know you care about these things, which is the main reason I brought it up in the first place. It's unlikely to be a quick fix.
 
By the way, at least in the USA, if anyone's curious about certain other frequently quoted laws and standards related to computer accessibility, Section 508 of the Rehabilitation Act of 1973 is one often-referenced statute (with standards that go with it). ADA stuff tends to spin off from Section 508 stuff.

There's also a lot of bleed-over these days between WC3/WCAG standards and Windows due to the prevalence of "web apps that don't really appear to be web apps" from the end user's perspective, but certainly are from a developer's perspective.
 
@britechguy
I've started looking at how to make apps that comply with screen readers and it appears that there is a lot of work to do on the interface. Today, it is clearly not usable using keyboard only. This and some other rules such as alternative texts, tab stop orders...
Today, this is nothing like that. It will take a while
 
Today, this is nothing like that. It will take a while

Which I knew before asking. But you can never get what you don't ask for and, as the old saying goes, "A journey of a thousand miles still begins with a single step."

You've now taken that first step. Who knows how long the rest of the journey may take. But I had to ask you to set out on it otherwise it might never have occurred at all.
 
Whether @fabs rewrites the UI for screen readers might depend on how big the AutoBackup Home & Office market is. I'm not sure if there'd be much need for screen readers for Pro customers.

Maybe the easiest solution is to write a script that runs in a terminal window with text prompts/output then runs autobackup with command line options. I'm sure screen readers would work well with that.
 
Often it's easier to do that than it is to understand the original version.

Particularly if you were trying to be "too clever by half" and were of the foolish mind (at the time) that commenting is for those with a weak mind.

I learned lessons early on that:

1. Code ultimately "compressed" in C syntax is virtually impossible to understand later if you were really, really trying for brevity versus clarity.

2. Even code not so "compressed" becomes non-obvious over time. That paragraph-length comment giving the birds-eye view of what the code in a given file or function does at the top, with stategic very brief comments interspersed in the code, is incredibly helpful.
 
I'm not sure if there'd be much need for screen readers for Pro customers.

It would certainly be a small market, but it's larger than you might think. IT work is one of the things that someone who can't see, and who is appropriately trained and motivated, can do very well indeed. Most of the coders who create screen readers themselves have never seen their own code in the literal sense of "see."

But if you (the generic you) are in the coding biz these days, and trying to serve a wide market, it really is worth learning to code with accessibility in mind as standard operating procedure. Particularly since Microsoft, Google, and a number of the other big players have been doing this for some time now, and it's become a baseline expectation in many circles (whether there's a huge market for it or not - it's one of those "things should be accessible on principle" things, since it's not onerous to achieve if it's built-in from the start).
 
Back
Top