Late this year, the Department of Education and Training required daycare services including Family Daycare services to transition to a fully-eletronic "Child Care Subsidy System" (CCSS). They supply a list of vetted and approved third party software providers to mediate between DET's CCSS and the FDC provider.
Which brings me to "Hubworks!" This company produces a hosted SaaS that amongst other things caters to family daycare services. You will be shocked to hear that this blog is not a ringing endorsement of their wonderful platform.
They managed to:
- Produce the worst online enrolment form I have ever seen, and I've seen some truly bad web forms;
- Have their support service ask my partner to send them her password;
- Write me off as a parent, because there's only one "Primary Parent";
- Trumpet on their website about all their amazing Web Based Web 2.0 with Bank Level Security while doing all this.
I reached out to Hubworks via support and internal channels months ago to raise some of these issues. I have been ignored and dismissed. My ticket has been marked "Fixed". So it's time to see if their marketing department cares more.
They've been very happy to direct me to seek support via the educator and the family daycare scheme, as "[t]his is policy of HubWorks! that we always direct parents back to the service as we do not provide assistance to families." From my experience so far, they also do not provide any assistance to the service or educators.
The Enrolment Form of Doom
Their enrolment form is awful. Have a look at any of these examples, easily plucked from Google.
Or this handy example I prepared to the right. Really, it's a damn impressive form, and you should recommend it to your local web design course for their "what not to do" gallery:
- It's a single gigantic Form of Doom that must be filled in one go. With 2 parents, 2 kids and 2 emergency contacts, it has something like 200 fields to fill, checkboxes to check, etc. I lost count. It is 30 browser pages, i.e. 30 page-down presses. 30. Printed, it is 16 A4 pages.
- If your browser crashes, your laptop or phone runs out of power, your phone decides to dump the page from memory when you task-switch from the browser, etc, horay! You get to start again from the beginning! There's absolutely no way to save the work-in-progress form if you, say, get interrupted by children or have go go look up one of the dozens of random details they require that you enter.
- There is no indication of which ones are required. You get to guess!
- Not a single field explains why they need that information, even when you have to enter the same thing as both an image-upload and by typing it in.
- There is no pre-submit validation, so good luck guessing whether they're happy with the data you entered!
- You have to duplicate both parents' details, once per child. There's a "copy family details for this child" option, at least, though it's a weirdly placed radio button. (A rare credit to them though: at least they recognise that both parents of the kids in care may not be the same).
- The form requires a minimum of two document uploads per child, each of which is limited to 2MB so in practice parents have to find a tool to resize their scan/photos before sending. User friendly for a wide audience!
- The uploads are done with as legacy multipart/form-data uploads, so the whole form must submit before any validation is performed, and no pre-submit file size check is done. Perfect for a wide audience with Internet services of varied performance and reliability! (But it's Web Based!, so it must be good!)
- Some of the uploads duplicate information you have to enter in structured fields anyway, so it's not clear there's even any point in having them.
- It doesn't offer you any way to save a copy of the form you submit before you submit it. Gee, imagine if I wanted to keep records. (This will be important later).
- The CSS is so messed up that to get something vaguely sane to print-to-pdf to save for my records, I had to use Chrome's developer toolbar to force Chrome to use the screen css for print. Because the print CSS is ... well, nonexistent, it's completely unusable. Alas, I only discovered how to make it vaguely printable later, when writing up a case for their support.
- There's a tiny "print" button down the bottom. Yay, maybe I can at least get a pdf-printable version of what I entered before I submit! .... nope. It's a link to download a hideous unstyled PDF form, with no actual PDF form markup let alone anything like PDF accessibility features, produced by "htmldoc"
- ... I could go on. Really.
I had the pleasure of interacting with this form while on holiday in another country, with unreliable slow Internet and with only brief opportunities to pull out a laptop. Imagine the fun! I think between my partner and I we filled the whole thing out at least four times before we threw up our hands in pure frustration. We decided we'd have to try to do it the night before the due date instead, so we could at least submit the form without it timing out while uploading numerous megabytes of random unnecessary scans over a slow, unreliable link.
Eventually, with teamwork, perseverance, and a strong desire for wine, we emerged victorious. Probably. Because the successful submit page that HubWorks!!! produces isn't what you'd call informative, and neither is the email it generates.
OK, you say. The first experience you have with the software is unbelievably awful, but really, how bad can the rest of it be?
Oops. Shouldn't have asked that.
The Primary Care Giver
After some hoop jumping for my partner to create her account, I sought out how to create mine. I did not receive an email like she did. I contacted support, and some time later discovered that I'm not allowed to log in, because I don't get an account, because I'm not actually enough of a parent. Only the "Primary Care Giver" gets a login. Hell, I'm amazed they didn't just hardcode it to "Mother", given the standard of the rest of the software.
Maybe you can check more than one "Primary Care Giver", but I have no idea, since it's not like there's any sort of context-help, tooltips, or live validation! I seem to remember I tried and it spat a validation error at me eventually, but I can't recall for sure in amongst all the errors I hit.
Gee, it's so lucky there aren't parents out there with legally mediated custody agreements (which the Form of Doom specifically asks about), parents with a history of domestic violence, or any other reasons you might not want to share a single user account and all your personal details.
Update: I got a reply from their support about this topic later, which read:
For multiple logins for parents that are separated this is arranged by the children having an enrolment under each parent and then the parent can access the system for their child, this also does not allow a breach of privacy of being able to view the accounts or details about the other parent as they are not able to see this at all. We don't currently have scope to provide a family with more than one login on each account but I will take it to the development team that this has been requested.
So I guess it's good they have a plan for this, even if it's a dodgy workaround.
Well. The Primary Care Giver got to deal with the next bit of fun.
Linking Our Child
One of our kids was pre-linked into the Primary Parent's account. The other was missing. I suspect this is because I typo'd his date of birth, which was a genuinely dumb mistake on my part.
Fixing this took a week or two of back-and-forth between the educator, family daycare service, and HubWorks!!11! support. The software insisted that we enter his "place of birth". Presumably, it meant exactly as written on the enrolment form, so you'd better be sure you remembered every comma and space, because it's not like HubWorks¡ sends you any sort of confirmation of what you submitted. Well, I have his place of birth shown three ways on three different documents. My partner and I tried every variant we could think of and got nowhere.
Support asked my partner for her username and password
When my partner reached out to HubWorks‽ support again, they asked her for her username and password so they could log in themselves and look.
Remember the part on their website where they mentioned "Bank Level Security"? Yeah, um, about that.
It'd be interesting to see what extensive list of compliance claims based on www.privacy.gov.au they make here have to say about asking for passwords. (At the very least they haven't updated their list since 2014, since the cited NPPs were replaced by the APP scheme then.)
I wonder if they have ever heard of "Phishing", or basic online security procedures? How on earth could any support operator ever need a user's password? OK, I guess it's good they can't just look them up in the database, but what professionally built system lacks a way for authorized support engineers to masquerade as an end-user when debugging issues? With appropriate supervisor authorization and while generating an appropriate audit trail, of course.
Lets see what everyone else does? Ah, right, a statement that "we will never ask you for your password" on their support pages, and usually on all their email communications.
Because they don't need to.
Honestly, I'm shocked they don't "encrypt" passwords with AES256 (because more numbers = more secure) not SHA1, so they can just decrypt them for support use. I'll certainly be surprised if they've managed to salt their hashes, and I don't think they'll hear about multi-factor authentication facilities like TOTP until the mid-2030s.
Update: I got a reply from their support about this later, which read:
We do not have access to the parents accounts and that is the reason we ask for the login details, we understand that not everyone feels comfortable supplying these but they can be changed at any time and this is the only access that we have to view the portal from the parent side.
That's actually what we did, as it happens, sent the password then changed it immediately. On the upside, it's good the service cannot simply log in as any end user without any sort of authorization or audit trail. They could've actually managed to do this one worse than they did. Props to them, 3/10. But seriously, asking for user passwords?
Eventually we got youngest linked to the account. I don't remember if we figured out the exact format we entered for the place of birth, or if support eventually worked something out. It's kind of a painful blur by this point.
We're Linked! Now, about that sign-in
Which brings me to yesterday. My partner dropped the kids off at daycare. They had a great day with our wonderful educator. I came to pick them up, and ... I had no way to sign them out. Because I have to use my partner's username (phone number, I think) and password.
Can we have another little chat about basic principles in security design? Hey, do you know one of the first things every service, ever, tells its users? Never share your password with anybody else.
In this case, meh, I just called and asked for her password. We're pretty chill about such things. But imagine if we were split parents in a mediated custody situation? Fun times!
After they went live with the new sign-in scheme, they got around to emailing me (with my partner's name!) to tell me that I could use my own registered phone number. It would prompt to set a PIN on first use. Fair enough, nice of you to explain before we actually needed it. It even worked!
Honestly, all this "primary parent" business and credentials sharing would be very simply solved by them calling it a "family account" and not binding it to one specific Primary Care Giver's (mutable) detail like a phone number.
Signing in and out - yup, still sucks
I can now sign in and out. Yay! There's nothing handy like a shortcut to stop you having to enter your phone number every single time, then a PIN, while juggling a cranky child. But I'll take it.
Of course, it's buggy and badly designed. It's a web based form hosted under the educator's login. The login times out. So you enter your phone number, then it ignores the phone number you entered and prompts for the educator login again. The educator has to come over and log in again. Then you re-enter your phone number. Sigh. You can to enter a dummy number like '0' to force it to refresh, but then it gets confused if it *hasn't* timed out yet because someone else used it.
Imagine if we had Web 2.0!1! Technology and could do things like make an XMLHTTPrequest to the server when user input is detected and pop up an educator login. Or, say, remember the user's entered data and resubmit once the educator logged in. Or, hey, here's a REALLY crazy idea, use client-side sessions for the login form (only, since they're less secure) so they don't have to expire! All these solutions and more, brought to you by any book about web programming after 2005!
This brochure from HubWorks! boasts of their advanced (ahem) use of AWS and their security excellence (256 bit encryption!), under a stock photo of a generic hip-geek. It even shows the planned streaming replica, implying they don't have one! Click for the full experience. It's actually an OK document, but when distributed to parents it's clearly meant to wow them with the technical wizardry and buzzwords. (Sorry about the poor scan, it's been kicking around a few weeks.)
The exclamation mark in the product name is so early-2000s. Like the product.
Their support page says:
We are listeningHubWorks! is here for children. We want the ultimate program, our children deserve that. If we can make you happy our children will be happy. So tell us, what do you want?
Well, seems they weren't listening.
I'd be less sarcastic about this steaming pile of dung if they didn't make such massive boastful claims about how amazing it was on their website. I'm a software developer myself. I'm personally culpable for the creation and release of some truly terrible software. I know our profession builds teetering houses of cards on a foundation of mud, spaghetti and chewing gum. I know the sales team drives release dates, I know QA is something we'll do "later", I know documentation is a rumour you once heard someone whispering about in a hallway. But come on... this is software for a general public audience, that makes tons of claims about how amazing and high tech it is. You don't get a pass.
Post a Comment
Captchas suck. Bots suck more. Sorry.