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
