Hi Adrian, Thanks a lot for the detailed feedback! I think it is exactly this kind of constructive criticism that helps the most.
I am on the MDN team, and in charge of maintaining the Firefox OS doc zone. You can feel free to aim any doc-specific stuff at me. I’d like to request that some of the platform developers try to find some time to help me work out where our documentation is out of date and in need of fixing. I ran through all the build process docs about 2-3 months ago in detail, checked that it all works, and made a number of updates, but it may well be time to do that again ;-) Your new article is very useful[1]; I have linked to it from the main Firefox OS zone menu[2] and from the Building and installing sublanding page[3]. I also gave it an editorial review, fixing a bunch of minor grammar/spelling/structural issues. All the best, Chris Mills Senior tech writer || Mozilla developer.mozilla.org || MDN [email protected] || @chrisdavidmills [1] https://developer.mozilla.org/en-US/Firefox_OS/Building_and_installing_Firefox_OS/Firefox_OS_build_overview [2] https://developer.mozilla.org/en-US/Firefox_OS [3] https://developer.mozilla.org/en-US/Firefox_OS/Building_and_installing_Firefox_OS On 13 Dec 2013, at 12:49, Adrian Custer <[email protected]> wrote: > Hello Andreas and the Mozilla phone team, > > > Thanks for all the great work making the "Boot to Gecko" idea into the > real phone I have in front of me! The real Firefox OS, for all the > criticism I level below, is a fantastic platform for the future. The > amount of work you have put in is huge so you all deserve a great thanks > for pulling it off. > > Yet there is still a long way to go to turn the existing platform into a > viable and vibrant system able to produce a great experience for users, a > viable infrastructure (and business?) for developers, and a competitive > alternative to the other phone systems. That's what this mail is about. > > Andreas, this is addressed to you since we met in Montevideo during the > launch and I figure you might have input into the overall process. It is > sent to the list as well since the individual comments about the apps might > be of use to those writing the Gaia apps and might elicit other discussion. > > > > > > Users are the ultimate key to making the project a success. If users > hate the platform, it is sunk; if they love it, they will leave room for > the inevitable mistakes and errors made along the way. > > I worry for the users of 1.1. I doubt any of us is dogfooding v1.1; it is too > painful. The clock app which only tells the time does not make any sense on a > phone that gives you the time in the top right corner. The browser was not > even up to the level of the early versions of Firefox for Android. > Fortunately 1.2 is better all over. So we need to get users past 1.1 as > quickly as possible. > > => Mozilla needs to publish the upgrade story. > > Mozilla should be putting out very clear signals about how those users will > get to upgrade. If Mozilla moves past 1.3 and I am stuck on 1.1 and all I > hear is ... nothing, I get frustrated. Even if upgrades are out of Mozilla's > hands, Mozilla should be coordinating with the device manufactures and the > telephone service provides to put out a very clear story on the situation. > From the point of view of a frustrated user, they ought to see Mozilla on > their side trying to get upgrades done, not as part of the problem. > > > > > > Which brings me to the User experience itself. I'm working from v1.2 > because that's what I have on my phone today. > > The Browser - You all had the gall to call this thing 'Firefox OS' > and then you come up with this browser! > You all know perfectly well that phoenix was started to break > away from the monolithic suite being pushed by Mozilla. Firefox > (born phoenix) was a project started outside Mozilla which aimed > to do one thing only and well, web browsing. That it eventually > dominated the integrated suite pushed by Mozilla insiders should > have prevented you from re-using the name for this insider driven, > "let's make the browser do everything" project. But, you squatted > the name anyhow. Well, now you better live up to the name! > So make the browser great. I know you have great plans for the > future but releasing this phone named after the browser with a > browser this trivial was bad marketing. (Yeah, go ahead, try using > the browser v1.1 for your browser needs for a day, I challenge you.) > Do better, make this great now, it is in the phone's name. Okay, in > v1.2 the browser is at least becoming 'painfully usable' but it > ain't worthy of the Firefox name and reputation. > The browser is not key to a phone, but you've taken the name so > now you have to make it GREAT, and quickly. > > Phone - works well so far. Cool. > > The Clock - v1.2 adds the Alarm clock and a Timer. Great, now it is > actually an app. The Alarm sounds leave a lot to be desired. Are any > of you willing to be heard in a meeting emitting these sounds when > the alarm goes off to remind you you have to go pick up your > sister's kids? The alarm actually survives long term, unlike > the timer which dies when opening another app (or two). That is > actually dangerous, since an obvious use is timing things on the > stove. Also, when I overcook my pasta because of a crummy Clock app, > I blame the phone, which is exactly what we want to avoid. > > Contacts - It's starting to be usable. The backup to sdcard saved me > lots of work when downgrading from v1.3 to v1.2 (which hosed the > contacts and SMS messages for some reason). So, good. > Adding a contact is less obvious. The UI is all backwards where > I have to look deep into the block to know what it is about. Can > any of you tell me what "Perso..." is going to be about? Oh, okay > this is an email field, and it is preset to not be 'work' and has > chosen something like 'Personal' as the text but doesn't fit. Having > that 'Company' field as the second entry is irksome, suggests this > has been developed by corporate land. Then in the phone number there > is this 'Carrier' thing which is puzzling. In Belgium, France, and > Uruguay, everyone knows the carriers by how the numbers start. In > the US, it does not seem to matter so much since you get charged up > the wazoo no matter who you call. So that field seems highly > detailed for the initial presentation on a general purpose phone. > So what's a good layout? Well say you just met steve in the > hallway and you're both late for class, so he gives you his email to > chat later. You want store 'Steve' the email adress and 'school' > quickly. You want something like: > > | ContactName | | | > | Last Name | | Photo | > | First Name | | | > > | phone number | [&details] + > > | email | [&details] + > > | tags | > > ... > When you have lots of time, you can worry about the details, but, by > then, it does not matter if they are a bit buried, you have time. As > for the big red minuses, they should not appear until there is > actually something to subtract; otherwise they are just raining on > my day. At the end of adding a contact, you are faced with > |X| Add Contact |Done| > Well, I keep clicking on the 'Add Contact', don't I? Oh yeah, after > a while I learn that the middle part is just a title and the right > part is the button, but by then, I've lost Steve's contact, hein? > Bummer, I kind of wanted to talk to Steve again. > As for editing a contact, oh lord. You edit, then are faced with > |X| Edit Contact |Update| > but wait, is that big, bad X going to delete the thing? Man, I > clicked on that head and shoulders with a pencil icon just to see > what would happen and now I really don't want to delete Silvia's > address. I don't dare do anything. Oh, well, home button it is. Grr, > that didn't help. Well here goes nothing...X. oh, it survived. Cool. > But what about deleting a contact, how do I do that? I can't. hmm, > oh well. (yes, it is possible, buried way down at the end of the > Edit dialog. You can delete a phone number block before you enter > anything into it but deleting a contact requires you to scroll way > past the details of a contact to find a button floating all on its > own. Strange UI.) > > => the |X| dialog dismissal button should always be a < back or > an escape symbol like up and left arrow. The |X| has too much > semantic baggage: you need to know what you are ex-ing, the dialog > or the content. (Same is true when editing SMS messages, for > example.) > > Messages- Works pretty well. > Well except when you are typing messages in languages other than > your locale which is an exercise in total frustration. Let alone > what a non-monolingual human being does which is write in several > languages at once: english with a quote in french, spanish but with > english directions, ... Have yet to find how to disable the > auto-correct. (Auto-correct has to be very, very, very good to be > better than no correction. As it is, I have to fight auto-correction > the whole way which is a pain.) > I keep hitting the 'home' button when trying to type the space > bar. At least the message survives when I reopen the app---nice. > Why is the 'Edit messages' which means deleting them, three > dots with a check mark? Very strange iconography. > > Clock - Why is bringing me back to the clock an 'Alarm' tab? 'Alarm' > is the clock, 'Timer' is where I set the timer, and 'Stopwatch' is > where I use the stopwatch. There's a severe lack of parallelism. > Still, if you all fix the timer so it survives until it rings > like the alarm does, then the rest is usable. > > Radio - Is cool. When you can separate out the 'need a headset as an > antenna' from the 'plugging in the headset means sounds come out > that way' it will be better. > > Music - Is getting better. Not sure why some albums are four times > the size of others--seems gratuitous. And since much of my music is > songs, not albums, they get lost. Remember 45's? But, I'll give that > a pass since organizing music effectively is a *hard* problem and > everyone has their own ideas. > > Gallery - works and will get better. Editing should be clear if it > will make a copy or modifying the existing photo (never). > > Camera - awful. But I was spoilt, just before dogfooding this phone, > by the cutting edge Google App which had finally gotten to be > usable finally and had some gimmicks beside (panoramas, 3D). > It's hard to get this right: how to let users specify what to > focus on and what to measure for exposure, how to let them quickly > change the exposure (and fix it across a series of shots, like in a > panorama wihtout ruining the next day's pictures), how to mess with > the white balance (and fix it across a series of shots). > Surely you all know this and are working on it. Not sure how > limited you are by the hardware. There's a long way to go to make > the camera solidly usable for snapshots, but also usable as a basic > but truly functional camera. > > Calendar - I killed the app because it keeps waking up and killing > all other backgrounded apps, i.e. the GPS logging app I am writing. > I suspect it loads itself periodically to check if any notifications > are needed to be sent, as a work around to missing API allowing the > backgrounding of small tasks. > > Email - I have not dared to try to use this. I'd rather use web > mail anyhow from a phone. > > Marketplace - Have not gotten too far with that. It works, the apps > suck. (A calculator is not crazy hard to write but a good > calculator does require a bunch of work to get working perfectly.) > > Settings - Works well overall. > What is the Geolocation setting, since I am going to be asked > whenever any app wants to access Geoloc? Is this a global over-ride? > Move Developer Settings into its own top level rubric already. > You all must know it's absurd to bury 'remote debugging' as a > scroll -> tap -> tap -> scroll -> tap -> scroll -> tap > option. > Also 'software updates' and 'About' should be top level. > Neither are 'information about the device;' both are worth exposing. > > So, as all the dogfooders know, the current experience is a mixed bag. > Things work; AMAZING! There are lots of rough edges; sniff. This was > unfortunately not a well planned review, because, after all that text, my > mail is really about developer concerns. > > > > > > > Developers! Developers! Developers! ... the CEO yelled on the stage to > the point where his voice cracks and everyone is embarrassed, because it > was the mantra of the day. Still, it's not entirely wrong. Firefox OS is > a platform for which you hope a lot of web apps will be developed. If > so, then let's clarify some work Mozilla could do to help us developers on > our way. > > 1. Provide developer bundles > > Andreas, you really ought to have a deal with your in-country partners > to provide Developer bundles. It's very little work for a big gain. You > sell the phones for $20 dollars more if you have to and the bundle has a > phone, a T-shirt and some docs, hopefully the contact point of your > developer outreach folk in country or of some local developer group. > More importantly, the phone actually works for development: i.e. it is rooted > (unlocked too would be polite), and runs at least v1.2 so we can plug it into > the App Manager. (Even better is if every phone is a developer phone but I > gather there is tradition against that.) > > As a developer, I want to feel like Mozilla has got my back. A developer > bundle does that. > > > 2. Let us make backups > > You need a real backup story. The easiest would be to put a small > amount of work to make the recovery image be able to backup and restore > to and from the SDcard. CyanogenMod and others have shown the lead on > this. Right now the backup story is: > 1. (((({{ Magic }}))))) Find a rooted boot.img file. > 2. boot into the bootloader (buttons or adb reboot-bootloader) > 3. 'fastboot boot rooted_boot.img' > 4. 'adb shell' > 5. copy the partitions to a file on the sdcard > 6. copy the partitions from the sdcard file to a safe place > or at least that is supposed to work. I did not get clean dumps that work as > backups, which may have been because I did not have a clear > story of what I was trying to do. My hide was saved by a hacker in > Venuzuela who provided the Magic step above and has provided me more > recent builds, and another in Japan who wrote a hacking guide. It'd be > nice if Mozilla were part of that solution mix. > > > 3. Explain your upgrade policy > > Get a clean, documented policy on upgrades. (This needs to be done for > users as well, as stated above.) Apparently, for legal reasons you can't > distribute images. Maybe, I don' know for sure. As I get it, the key > might be that you can't distribute the binary blobs I already have on my > phone. Well, give me the policy and let's figure out what we can do. You > want me on 'master' because you want me submitting relevant bugs to your > developers. You also want me on 'master' so I don't have to trip up over > bugs that are fixed. I have real work to do like writing touch handling > code that can survive on this flaky hardware. You don't want me to waste my > time writing a test app that shows that the canvas flips upside down in > landscape mode on v1.2 if it's already fixed in 1.3. So let's all help each > other and make it easy for app developers to follow the latest branches. At > the very least, you want to get all developers onto version 1.2. That is what > works with the Firefox App Manager and you want us working there so we are > using the great work the Developer Tools folk. > > > 4. Fix the docs > > The docs, as you well know, are important. However, they are now an > accumulation of information which lack coherence and are partly out of > date. The build docs for instance, either start with a curl command > grabbing the bootstrap script from the source repo or with a git command > cloning the whole B2G repository. It takes a while to figure out these > are merely the same steps in a different order. > > You need to schedule regular time for your developers to review or even > write the docs. (Or even be able to answer questions for those who would > be willing to pitch in and fix docs.) Probably this make sense at > the end of each release. Since developer.moz.org just changed over to a > new system, it will take time for your developers to get going on the new > system. Regardless, schedule regular doc time. > > > 5. Clean and split the build > > Finally, the build is a monstrosity. It is massive in size, hides > gigabytes of repositories in the hidden .repo directory, uses a clutter > of tools cascaded into each other, mixes different output directories, > and generally reads like a long sequence of kludges. No sir, I don't > like it. > > As I have deciphered it so far, > * the setup step gets the required binaries, > * the configure step > 1. downloads or updates all the repositories > 2. writes the .config file of environmental variables > * the build step > 1. checks the repositories are up to date > 2. makes a backup of what is on the phone > 3. does the whole build > but really, I got tired of trying to trace the build logic. That's the > script's job. > > I imagine the build itself is actually six separate steps: > 1. Build the Android tools > 2. Build the kernel > 3. Assemble the root disk image > 4. Build the Gonk Components > 5. Build Gecko > 6. Build the Gaia apps > and somewhere it would assemble the kernel and root disk into the > boot.img, Gonk, the binary blobs, and Gecko into the system.img, Gaia > into the userdata.img, and the kernel, rootdisk and separate init script > into the recovery.img. But maybe it does not actually make images but > rather directly copies files to the device partitions; it is a kludge, > so surely it does the shortcut first and the clean build as an addon. And > maybe my understanding of what image has what is wrong. Still, since it's > going to fail along the way, it would be useful to know where it is failing. > If failing in step 1, then I ought to be able to blast past it; I've found > 'adb' and 'fastboot' binaries that work for me. If failing in the second > step, I'd like to know if I actually care---for what do I need a newer > boot.img (kernel and rootdisk) on this phone? > > I would like the flashing step to be very, very, very clear about what > it is doing. There is a slight danger that it messes things up badly and > causes me to waste a lot of time fixing my phone so I want to be able to > follow the flash.sh script to see exactly what it is going to do. > Really, I want to do it by hand first. (And having default behaviour be > to write into every partition on the phone is an approach only some well > paid coder using paid for hardware could have designed.) > ./flash.sh > should just spout information not potentially brick my phone. > ./flash.sh --all > can be brutal, the flag shows I know what I am asking for. Right now I simply > won't run that script: the real script seems to start with a while loop on > line 226 but the whole thing makes me nervous; I ain't giving it control of > my phone. > > Yes, I realize you are building on the 'repo' tool and the ASOP build. > That does not seem sufficient excuse for the current system. There must > be some way to make this all cleaner. > Backup phone: > Download/Update source: > Compile in separate steps: > tools, kernel, gonk, gecko, gaia. > Assemble separately: > tool binaries, boot.img, system.img, userdata.img, recovery.img > Flash onto device each separately, or using fastboot. > I've documented what I have figured out so far on: > https://developer.mozilla.org/ > en-US/Firefox_OS/Building_and_installing_Firefox_OS > /Firefox_OS_build_overview > because that is the high level overview I would have wanted before > trying to build FxOS. However, on #b2g yesterday, I was told that > flashing whole images is not what I should be doing. So someone in the > know ought to clean up that page based on the reality of what is going > on, and then integrate it into the start of the 'Building' thread on the new > dev.moz.org site so as to give developers a good understanding of what the > build is going to be doing. > > > 6. Improve Communication Channels > > My experience this past month interacting with Mozilla is essentially of > being completely ignored. > > The IRC channel is mostly dead. Occasionally you talk amongst yourselves. If > I ask a question there, at best I will get an answer many hours later. Still, > thanks for the answers along the way. > > Bugzilla reports get read quickly. Good. However, they do not get confirmed > or denied. I am not sure when bugs are due to my setup and when they are > actual bugs. That is frustrating. That first triage step should be happening > daily, especially since you can probably close a bunch of these bugs > immediately which both helps your bugzilla count and helps the submitter > figure out what they did wrong. There are also what I would consider > showstopper bugs which are apparently totally ignored. Poor users. > > This is my first mail to the list, so we will see how this form of > communication goes. > > Obviously you all are busy. However, if developers are a key to success, you > should have some regular mode of interaction with them. Perhaps that takes > the form of a weekly developer hour (or three to span the global timezones). > Mixed with fixing the docs, that makes for regular progress helping > developers, makes them feel part of the process, helps them get their work > done. > > > > > Well that's my feedback from a month of using and hacking on the platform. I > wasted lots of time upgrading to v1.2, I got badly tripped up by the manifest > switch to requiring absolute paths everywhere, I am stuck in portrait mode by > the canvas flipping upside down in landscape mode bug, I lost time on the > error 'unknown' when writing the SDcard, and now am in the middle of trying > to handle touch events on flaky hardware. After that, I hope to get back to > actually writing the GPS app I am trying to write in the first place. > > So cheers for all the good work so far. It looks like you are on a fantastic > path forwards. There are some tweaks needed. Primarily though there is a need > for better communication. Let users know about upgrades, help developers get > their work done. Let's put the web and its apps in everyone's pocket. > > cheers, > ~adrian > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
