Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redesign the UI so that it follows the flow of user operations #117

Closed
pbatard opened this issue Jan 11, 2013 · 7 comments
Closed

Redesign the UI so that it follows the flow of user operations #117

pbatard opened this issue Jan 11, 2013 · 7 comments
Assignees
Milestone

Comments

@pbatard
Copy link
Owner

pbatard commented Jan 11, 2013

Rufus users (understandably) appear confused that the order in which Rufus presents the various elements is not the order in which they are affected. For instance, one may select a File System only to have it overridden after selecting an ISO.

To make the whole operation more intuitive, Rufus should present the following in order, as each item is independent from the one before, but has an impact on the one that follows:

  • Device
  • Partition Scheme (MBR, GPT)
  • Boot Type (Non Bootable, MS-DOS, FreeDOS, ISO Image, Disc Drive, Folder, VHD, Bare Syslinux, etc.)
  • File System
  • Cluster Size
  • Boot options
@ghost ghost assigned pbatard Jan 11, 2013
@BavoB
Copy link

BavoB commented Feb 24, 2013

That would indeed clarify things in the UI.
And make it even better...

@pbatard pbatard modified the milestones: 2.10, 2.5 Feb 13, 2015
@BavoB
Copy link

BavoB commented Mar 24, 2015

Hallo Pete,

a. I'm still hoping you'll implement this rather sooner than later, in light of the fact that a lot more combinations (boot types and file types) are becoming available.
b. Regarding NTFS and other filesystems you are starting to supprt for UEFI booting: do you think UEFI forum might change/adapt the spec to overcome the 4GB filesize limitation of FAT32 by including maybe something like exFAT? (I suppose NTFS will be difficult as it is probably a closed spec)

Thanks for you hard work.

Best,
Bavo

@pbatard
Copy link
Owner Author

pbatard commented Mar 24, 2015

I'm still hoping you'll implement this rather sooner than later

Then you'll probably be disappointed as this enhancement is not sitting very high on my priority list right now.

First of all, this will be exceedingly more time consuming that you can imagine, especially when factoring the need to update all 30+ localizations (and God forbid you find an issue or change your mind and want to quickly update some part of the UI). For instance, the minimal changes that were introduced to the UI for Windows To Go and the new info field, in Rufus 2.0, required a lot more work than than people realize. And when it comes to getting these changes localized, you can add months of additional delay. For instance, even though I provided them with the data to update more than 2 months ago, long before the release of Rufus 2.0, I'm still waiting for a couple translators to provide me with their localization update... And I'm afraid this is not an unusual occurrence.

So unlike anything else in Open Source, when it comes to improving an UI, you can't really be nimble and go incremental by trying something here, something else there and addressing what works and what doesn't.

Also, as far as I am concerned, UIs are one of the hardest things in Software Development.

Encryption, compression, bring it on! That's really peanuts compared to trying to design an UI that most people will be happy with. This is because no two people ever have the same idea of what makes an intuitive UI. To bring home this point, about once a month, I seem to get into a heated discussion on how the Rufus UI should be redesigned to be more intuitive - I actually had my last private conversation about this no less than a couple of days ago...

Still, I wouldn't mind if you could elaborate on what you have in mind with regards to reworking the UI, bearing in mind that, by design, Rufus will remain close to the default formatting dialog from Windows, as this is something I expect users to be familiar with. I strongly believe that the more you can make a user feel on familiar ground when it comes to preforming a daunting task (most users find formatting an USB daunting, as they know it means data loss), the better it is. So what I really have mostly in mind with this enhancement is to reorder the way in which the various options and controls are presented, so that they follow the more natural flow in which users are expected to change them.

Regarding NTFS and other filesystems you are starting to supprt for UEFI booting: do you think UEFI forum might change/adapt the spec to overcome the 4GB filesize limitation of FAT32 by including maybe something like exFAT?

As far as I know, the only reason the EFI committee went with FAT32 is because the license was already open enough so that they could make Microsoft agree into providing them with a special licensing agreement that entitles them to use FAT32 without any form of restrictions. My guess is that this is probably because Microsoft considers that the FAT format as a whole is not advanced enough to warrant much IP rights, and their lawyers/accountants probably said it was OK to let it go (because they didn't expect to milk it that much more).

On the other hand, Microsoft appears to have been taking a very different stance when it comes to exFAT and NTFS and no such special licensing deal for those has been struck with the UEFI people, even if they are backed by juggernauts like intel. It's also fair to surmise that the UEFI guys were probably well aware of what using FAT32 would mean in terms of filesize limitations, and they probably tried to pressure Microsoft into getting a special licensing agreement for NTFS or exFAT... but failed.

So to answer your question: I doubt it. If intel and consorts didn't manage it at the time, it's unlikely that Microsoft is going to change their mind now, and decide to open something like exFAT.

The one thing I am puzzled about however is why the EFI committee didn't go with UDF, which is a fully open file system, that didn't have the 4GB limitation and that was already well established across OSes (and was designed to accommodate pretty much any media, and not just Optical Drives).

In my mind, I think the discussion probably went something like this:

  • [Intel] Hey Microsoft, we'd like to have unrestricted free access to a filesystem that can accommodate 4GB files for EFI. How about we use NTFS or an updated version of FAT such as exFAT?
  • [Microsoft] Get out of here! We have IP on those and we're gonna milk it to the ground. Now, if you were to agree to give us a piece of that juicy EFI pie, with some kind of fee for each implementation of our filesystem, maybe we could come to an arrangement...
  • [Intel] OK. Guess we'll just use UDF then...
  • [Microsoft] Alright, alright, tell you what: because I'd rather have people tied to something proprietary that comes from us, I'll give you a no strings attached FAT32 special license, if you promise to conveniently forget about that 4GB limit. How's that sound?

@BavoB
Copy link

BavoB commented Mar 24, 2015

Pete,

Thanks for your reply:

  • Concerning UI: ’m not a programmer but I can imagine ui’s are not easy, and sorry about all these discussions taking up your time ☺ ==> I’m only advocating minimal changes, a logical (re)ordering so all actions are predictable, no more.
  • File systems: yes I expected something like this – but out of curiosity if I understand correctly you already provide a fix in the latest version for NTFS/exFAT not being directly supported by the UEFI firmware. This works by Rufus loading an NTFS file system driver and putting most stuff in a separate NTFS partition that is not subject to FAT limitations (again if I understand correctly). But are you not afraid MS will come after you (or after me for using your program ;-)

Thanks for your reply, I truly appreciate you educating us on this ==> maybe musings like these could be put on your website?

Bye,
Bavo

@pbatard
Copy link
Owner Author

pbatard commented Mar 24, 2015

I’m only advocating minimal changes, a logical (re)ordering so all actions are predictable, no more.

OK, then I guess we more or less agree here.

This works by Rufus loading an NTFS file system driver and putting most stuff in a separate NTFS partition that is not subject to FAT limitations (again if I understand correctly). But are you not afraid MS will come after you (or after me for using your program ;-)

For the record, everything about NTFS UEFI support in Rufus is detailed here.

And you can be certain there are no licensing issues because:

  • The read-only NTFS driver comes from the GRUB GPL implementation of it, which was reverse-engineered in a clean room manner. While I know that an alternate proprietary NTFS EFI driver exists (of doubtful licensing & origin...), I pretty much spent the best part of a month creating my own completely independent version of an NTFS (and other filesystems) EFI driver(s), that is fully GPLv3 and doesn't come from non-free license encumbered reverse engineered sources. Therefore I can affirm with certainty that the driver I provide in Rufus is legally immune to licensing issues from Microsoft. Heck, I even made sure I didn't even take a peek at the FAT32 driver implementation from the EDK2 (the Open Source UEFI development project). And yeah, sometimes, spending months recreating the wheel, just to ensure that your users will not be in breach of any license is what it takes in the Free Software world... The whole efifs project is just a byproduct of wanting to add EFI NTFS support in Rufus, in a completely Free Software manner, really.
  • The rest of UEFI:NTFS is also fully GPLv3 and was developed outside of any proprietary licensing or IP. There again, I spent a lot of time making that I wasn't looking at anything that could taint the project in any way.

I have to stress out that I am NOT using the NTFS EFI driver that, is known to have been floating around the internet, and that nobody seems to be knowing the provenance or licensing of.

So, if Microsoft want to come after you for using NTFS EFI support in Rufus, they'll first have to come after the whole GRUB project, which they haven't done for the many years that the project has existed, and for good reason, since I know the GRUB people have been working hard to make sure that there wasn't anything that could remotely let Microsoft build a case against them.

Clean room reverse engineering is perfectly legal and Microsoft knows this better than anyone else, as it's clean room reverse engineering (of the original IBM-PC BIOS by Compaq) that made them the company they are today (by ensuring that PC compatible clones, running Microsoft software, could take over the world)...

maybe musings like these could be put on your website?

I try to keep http://pete.akeo.ie for technical stuff only (with perhaps a few musings in passing, but only if they don't distract too much from the technical stuff). And if I were to do it on http://rufus.akeo.ie, I'd have to ask 30+ translators to translate those, which I don't really want to do...

@BavoB
Copy link

BavoB commented Mar 24, 2015

Re UI: no, I TOTALLY agree with you ☺, nothing more than your own description in the GitHub log, and on your timing…

Re NTFS and other file systems: well I must say I take my hat off to you sir, I was not aware of what it takes...

Also: patents should not make it so difficult for programmers like you to be able to deliver useful functionality. As far as I’m concerned MS already makes enough money, and it is not like you’re trying to replace Windows as an OS. I realize we live in a capitalist world, but I think for IP there should be a ‘fair use’ clause, like there is for journalists and artists when they want to use works protected by authorship, provided they stay within the intended use. That would make perfect sense in your case too. But no MS lawyer would ever like that concept, I’m afraid.

@pbatard pbatard changed the title ER: Redesign the UI so that it follows the flow of user operations Redesign the UI so that it follows the flow of user operations May 8, 2015
@pbatard pbatard mentioned this issue Aug 5, 2016
3 tasks
pbatard added a commit that referenced this issue Mar 22, 2018
* Better guide the user through the flow of operations
* Also follow a concept design by Fahad Al-Riyami
* Closes #117
@lock
Copy link

lock bot commented Apr 6, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.

@lock lock bot locked and limited conversation to collaborators Apr 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants