SparkFS 1.52 Choices
Pages: 1 2
Frederick Bambrough (1372) 835 posts |
SparkFS 1.52. Is the Close icon intentionally missing from the Choices window? A bit inconvenient/odd. Can’t step back without closing the app or hitting Save. |
David Pilling (8394) 93 posts |
Hi Fred, on gitlab removing the close icon is written up as style guide compliance. |
Frederick Bambrough (1372) 835 posts |
Intentional then. OK. Does it say why :-). Should there be a Cancel in window? |
David Pilling (8394) 93 posts |
Over to those who know – the close icon is something you often see, but it does not feel right. |
David Pitt (9872) 341 posts |
Page 50 of the Style guide refers, see “Persistent dialogue boxes”. Close icons are a must not, on closing it would be unclear whether any actions would be implemented or lost, it says. There should be a Cancel action instead, it says. The text is copyright and the PDF locked so it not quoted here. Let the litigation commence. |
David Pilling (8394) 93 posts |
But it is not one of those situations where cancel could reset things. If you click on a setting in choices it has immediate effect. There is no mechanism for Cancel to put things back how they were – reload the choices file if you like. Save writes to the choices file, and will have an effect the next time the program is run. It is convenient to change the compression type to None, get rid of the choices window, mess about with archives, and be happy that next time choices will be re-loaded with the old settings. |
Frederick Bambrough (1372) 835 posts |
I suppose then, that if one makes no changes the done thing is to select ‘Save’ anyway. |
David Pitt (9872) 341 posts |
User choices, p91, in the Style Guide looks to better cover the situation. (Still no close window icon though!) A Set button makes changes for the current session without saving. Thank you for the explanation of how this element of SparkFS work. |
Chris Mahoney (1684) 2162 posts |
I haven’t seen the dialogue box myself, but do I have this right?
It almost sounds like there should be separate “OK” and “Save” buttons, although then we’re back in the land of confusion. I wonder what the best option is here… Edit: As pointed out, page 91. The example dialogue there has both Set and Save buttons. |
Steve Fryatt (216) 2095 posts |
Ah… that’s where you’re going wrong, then. Page 51 of the Style Guide says “Both types of dialogue box1 should be characterised by delayed action: the user has to make choices and then click on OK … before the choices take effect. This contrasts with the instant effect of, for instance, dragging a scroll bar. Toolboxes … have an instant effect.” (my emphasis). So you then have a Set button to apply the choices (using Adjust to keep the dialogue open for more fiddling), optionally Save to make the values the new default for the future, and Cancel to forget the changes (or reset the dialogue contents if Adjust is used). But no close icon, as it isn’t clear to the user whether that will Set, Save or Cancel any changes which have been made. 1 Persistent and Transient. |
David Pilling (8394) 93 posts |
@Chris Mahoney you have summarised the situation correctly. |
Steve Fryatt (216) 2095 posts |
Having gone to check, it looks and quacks like one, though: it’s accessed via a menu entry with an ellipsis (which the Style Guide tells us leads to a persistent dialogue box), and has an action button labelled “Save” in the place that you’d expect to find one in a dialogue box. Given that other bits of the OS generally use the delayed-action approach, I’m assuming that’s the way that ROOL are trying to move SparkFS. Presumably whoever made this change hadn’t noticed that the dialogue didn’t actually work as expected, however. It would be nice if that work was completed1, but the expedient option for now might be to restore the close icon and change the “Save” button to read something like “Update Defaults” or “Make Default” so that it can’t so easily be confused with a button that applies pending changes. 1 Assuming the work is done correctly, the only change to the user experience is the need to Adjust-click on a Set icon to make the changes apply and leave the dialogue open. It’s one more click, but makes things consistent across the OS. |
David Pilling (8394) 93 posts |
@Steve Fryatt – sounds right to me. If I do another weeks work, I’ll do Zip encryption. |
Martin Avison (27) 1479 posts |
That would be really brilliant! |
David Pilling (8394) 93 posts |
Spark files/dirs support Garble (32 character password) and DES (8 character password (limitation of the algorithm), extra characters ignored). Garble is trivial to break. DES has fallen out of favour. |
Rick Murray (539) 13751 posts |
One could argue that weak encryption is worse than no encryption. As you mention: |
Colin Ferris (399) 1798 posts |
I wouldn’t be surprised if there weren’t several gov computers keeping the Tea warm trying to break code :-) |
Martin Avison (27) 1479 posts |
@David P: I know there was a printed manual for SparkFS, as I am looking at mine, for v1.22 dated 24 Feb 1993! I know it is out of date, but it would be good if the Ovation source could be found and made available to ROOL if not already – perhaps then it would be possible to update it? |
Rick Murray (539) 13751 posts |
There’s a PDF on his website. It’s not long, about 30 pages. |
Frank de Bruijn (160) 228 posts |
This. I’d rather have no encryption than something that isn’t worth the name. That could just give a false sense of security. |
Stuart Swales (8827) 1326 posts |
But then again it is nice to be able to open zips that have been encrypted… |
David Pilling (8394) 93 posts |
The Ovation Pro version of the SparkFS manual is here: https://www.davidpilling.com/software/sfsman.zip I stopped updating it in 1993, there is much useful material in the ReadMe. Nice project for someone to write a new manual, although not much incentive, if there are going to be user interface changes. Encryption… I read the paper Rick referenced above, interesting. It is a big debate. My POV is making small achievable steps. Once you have any encryption for zips it is easier to add other methods. What’s the end user of RISC OS these days – military, organised crime, people who cheat on their partners… |
Chris Johnson (125) 825 posts |
With respect to the behaviour, look, etc, of the Choices window in SparkFS, the Choices/Settings windows in SyncDiscs and Snapper behave in a somewhat similar manner. DPlngScan also has some differences to the Style Guide in it’s various settings dboxes. Maybe I should take a look at these apps with a view to checking on style guide compliancy, and modifying where possible. |
David J. Ruck (33) 1586 posts |
I disagree, you aren’t always trying to protect against nation state level interception. You wouldn’t put confidential information on a postcard, you would use an envelope, even though its easily cracked it prevents casual interception. The same with email, for many years some RISC OS dealers required you to email credit card details for payment, if you used plain text it could be easily scanned and intercepted by any compromised email gateway. Putting the details in a weakly encrypted zip (or even something obscure like a drawfile) raises the bar too high for not all, but the vast majority of threat actors. |
Steve Pampling (1551) 8126 posts |
Probably true. |
Pages: 1 2