This is a follow-up bug to Bug 1195358 for visual edits.

Hi, Attached is a 3-page pdf of visual edits. I also edited the CSS for layout of the main screen (will attach css file). Adjustments were made to fonts, positing, sizing elements, etc. Anything that I couldn't fix is outlined in the PDF. Also 2 things to note for UX 1. In step 2 (Select), the user is allowed to select any file for upload. Should this be limited to compatible files? What happens when they try to flash with an incompatible file? Jacqueline to confirm. 2. If I select a file using the uploader and then upload another file, it should replace the previous file and not add another radio button option. Let me know if you have any questions. Thanks!

Edited CSS

1. If we have a list of files that are compatible it would be helpful to restrict the ones that aren't, otherwise we would need to display an error to the users that this file will not work. I can provide the error screen if it is necessary. 2. I agree, I was under the impression that the user would use a single file to flash onto their device and I think it confuses the UI to support more than one.

Hi Dale, Can you please replace the H1 header (Firefox OS Installer) with the attached png? Thanks!

(In reply to Jacqueline Savory [:jsavory] UX from comment #3) > 1. If we have a list of files that are compatible it would be helpful to > restrict the ones that aren't, otherwise we would need to display an error > to the users that this file will not work. I can provide the error screen if > it is necessary. The list of builds that we are exposing to the user is the set we find that indeed compatible with the plugged in device. Builds are coming with a devices.json that documents compatibility, so it should be safe from this point. We might still benefit from an error screen UX for the case of the user picking up a local file: we will also check the compatibility with the plugged in device, but technically this will happen after we opened the blobfree distribution ZIP. > > 2. I agree, I was under the impression that the user would use a single file > to flash onto their device and I think it confuses the UI to support more > than one. No, we really do want and need to expose several compatible builds and allow local loading. Maybe we could make the separation cleaner: - have a dropdown list for picking up an hosted compatible build - just add a radio button for picking up a local build and maybe hiding the dropdown?

Pretty much all aside from the native form elements