Foxkeh Strikes Again!

mitcho

April 30, 2009

6:12 pm

I just wanted to point out that our beloved Foxkeh is featured1 on apple.com! He can be found on the Twitter business profile page in the first photo in the gallery:

foxkeh.jpg


  1. Okay, maybe “featured” is a strong word… 

Related Posts

  1. Foxkeh demos Ubiquity Parser: The Next Generation
  2. Updating your zenphoto theme for zenphoto 1.1

Related posts brought to you by Yet Another Related Posts Plugin.


Personas Gallery is Quickly Expanding

suneel gupta

4:46 pm

Four weeks ago, the Personas Team — with your support — released version 1.0 of the Personas experiment with a friendlier look and feel, improved functionality, and an expanded gallery of designs. Since the launch, Personas has been downloaded over 2.5 million times and has exceeded 1 million active daily users (see graph below from AMO). More importantly, we have welcomed over 3,000 new designers and over 5,000 new designs to the Personas community.

personas-uptake1

opportunities to collaborate with the Personas team

Members of the Personas community are now submitting designs faster than the Personas team can approve them, which has led to a large queue of designs waiting for approval. This is a nice challenge to have, and we are working diligently to evaluate and approve designs that meet the program’s terms of service. The immediate goal is to reduce the size of the approval queue. The near-term goal is to reduce the amount of time a community member needs to wait between submitting a design and being able to view that design in the gallery and share it with friends. If you are interested in collaborating with the Personas team on these goals, please send an email to personas@mozilla.com.

Other ways to help:

– suneel gupta, on behalf of the Personas Development team


Adding Your Language to Ubiquity Parser 2

mitcho

April 29, 2009

3:44 am

NOTE: This blog post has now been added to the Ubiquity wiki and is updated there. Please disregard this article and instead follow these instructions.

You’ve seen the video. You speak another language. And you’re wondering, “how hard is it to add my language to Ubiquity with Parser 2?” The answer: not that hard. With a little bit of JavaScript and knowledge of and interest in your own language, you’ll be able to get at least rudimentary Ubiquity functionality in your language. Follow along in this step by step guide and please submit your (even incomplete) language files!

As Ubiquity Parser 2 evolves, there is a chance that this specification will change in the future. Keep abreast of such changes on the Ubiquity Planet and/or this blog (RSS).

Set up your environment

If you’re new to Ubiquity core development, you’ll want to first read the Ubiquity 0.1 Development Tutorial to learn how to get a live copy of the Ubiquity repository using Mercurial. Once you’ve set up your Firefox profile to use this development version, make sure to try changing the extensions.ubiquity.parserVersion value to 2 in about:config (as seen in this demo video) to verify that Parser 2 is working for you.

As you read along, you may find it beneficial to follow along in the languages currently included in Parser 2: English, Japanese, Portuguese, and Swedish (and the incomplete Chinese and French).

The structure of the language file

Each language in Parser 2 gets its own file which acts as a JavaScript module. You’ll need to look up the ISO 639-1 code for your language… Here we’ll use English (code en) as an example here and the JavaScript language file would then be called en.js and go in the /ubiquity/modules/parser/new/ directory of the repository.

Here is the basic template for a Ubiquity Parser 2 language file:

1
2
3
4
5
6
7
8
9
10
11
12
var EXPORTED_SYMBOLS = ["makeEnParser"];
 
if ((typeof window) == 'undefined') // kick it chrome style
  Components.utils.import("resource://ubiquity/modules/parser/new/parser.js");
 
function makeEnParser() {
  var en = new Parser('en');
 
...
 
  return en;
};

After lines 1-4 which set up the JavaScript module, everything else is wrapped in a factory function called makeLaParser (for Latin) or makeEnParser (for English, en) or makeFrParser (for French, fr), etc. This function initializes the new Parser object (line 7) with the appropriate language code, sets a bunch of parameters (elided above) and returns it. That’s it!

Now let’s walk through some of the parameters you must set to get your language working. For reference, the properties the language parser object is required to have are: branching, anaphora, and roles.

Identifying your branching parameter

  en.branching = 'right'; // or 'left'

One of the first things you’ll have to set for your parser is the branching parameter. Ubiquity Parser 2 uses the branching parameter to decide which direction to look for an argument after finding a delimiter or “role marker” (most often, these are prepositions or postpositions. For example, in English “from” is a delimiter for the goal role and its argument is on its right.

     
to Mary from John

So “John” is a possible argument for the source role, but “Mary” should not be. Ubiquity can figure this out because English has the property en.branching = 'right'.

In Japanese, on the other hand, the argument of a delimiter like から (“from”) is found on the left of that delimiter, so en.branching = 'left'.

     
メアリー -から ジョン -に
Mary from John to

In general, if your language has prepositions, you should use .branching = 'right' and if your language has postpositions, you can use .branching = 'left'.

For more info:

Defining your roles

  en.roles = [
    {role: 'goal', delimiter: 'to'},
    {role: 'source', delimiter: 'from'},
    {role: 'position', delimiter: 'at'},
    {role: 'position', delimiter: 'on'},
    {role: 'alias', delimiter: 'as'},
    {role: 'instrument', delimiter: 'using'},
    {role: 'instrument', delimiter: 'with'}
  ];

The second required property is the inventory of semantic roles and their corresponding delimiters. Each entry has a role from the inventory of semantic roles and a corresponding delimiter. Note that this mapping can be many-to-many, i.e., each role can have multiple possible delimiters and different roles can have shared delimiters. Try to make sure to cover all of the roles in the inventory of semantic roles.

For more info:

Entering your anaphora (“magic words”)

  en.anaphora = ["this", "that", "it", "selection", "him", "her", "them"];

The final required property is the anaphora property which takes a list of “magic words”. Currently there is no distinction between all the different deictic anaphora which might refer to different things.

Special cases

Some special language features can be handled by overriding the default behavior from Parser. Many of these features are still in the works, however, so we’d love to get your comments!

Languages with no spaces

If your language does not delimit arguments (or words, more generally) with spaces, there will be a need to write a custom wordBreaker() function and set usespaces = false and joindelimiter = ''. For an example, please take a look at the Japanese or Chinese.

Case marking languages

If you have a strongly case-marked language, you’ll have to write some rules to identify those different cases in wordBreaker() and then add some extra roles for these case markers, but for a number of languages the current design does not allow an elegant solution for parsing such arguments. Updates to this issue will be posted to this trac ticket.

In the mean time, however, if you could write a parser even with only the prepositions/postpositions in your language, that would be a great benefit in getting started in your language. UPDATE: a proposal on how to deal with strongly case-marked languages has been written here: In Case of Case….

Stripping articles

Some languages have some delimiters which combine with articles. For example, in French, the preposition “à” combines with the masculine definite article “le” but not “la”:

  1. à + la = à la
  2. à + le = au

You can add both “à” and “au” as delimiters of the goal role, but then you will get feminine arguments back with the determiner (e.g. “la table”) while masculine arguments would be parsed without a determiner (e.g. “chat”).

  1. à la table” = “to the table”
  2. au chat” = “to the cat”

One possible solution to this is to write a custom cleanArgument() method. After arguments have been parsed and placed in their appropriate roles, each argument text (say, “la table” or “chat”) are passed to cleanArgument(). You can simply write a cleanArgument() to strip off any “la ” at the beginning of the input and return it and both example inputs will get normalized arguments: “table” and “chat”, respectively. UPDATE: For more up-to-date information on how to deal with these types of articles, please see Solving a Romance Problem.

Test your parser

Now you can go into about:config and change extensions.ubiquity.language to be your language code and restart. All the verbs and nountypes at this point will remain the same as in the English version, but it should obey the argument structure (the word order and delimiters) of your language.1 If you run into any trouble, feel free to ask for help on the Ubiquity i18n listhost or find me on the Ubiquity IRC channel (mitcho @ irc.mozilla.org#ubiquity). Of course, once you’re at a good stopping point, please contribute your language file to Ubiquity!

More to come…

At this point, you’ve only localized the argument structure of your language… additional work will be required to localize the nountypes and verb names, which is the subject of ongoing discussionjoin the Google Group to get in on the discussion!


  1. At this point in time it’s also possible to test your parser at chrome://parser-demo/content/index.html if you make a couple other changes to your code… for more information, watch the Foxkeh demos Ubiquity Parser TNG video. This option gives you more debug info as well. 

Related Posts

  1. Ubiquity Parser: The Next Generation Demo
  2. Rolling out the Roles
  3. Foxkeh demos Ubiquity Parser: The Next Generation

Related posts brought to you by Yet Another Related Posts Plugin.


Command Chaining with Oni?

mitcho

1:41 am

There are two challenges to implementing so-called command chaining, but only one of them is choosing a linguistically appropriate structural standard and parsing it. The other is the underlying difficulty of processing each individual “clause” in sequence, asynchronously. Alex Fritze blogged about how a project like his own Oni could dramatically simplify this underlying process.

Ubiquity, Oni, and Composability:

but I cannot instruct it to give me list of translated google results:

translate (google foo) to German  // doesn't work

Or email me the resulting list:

email(translate (google foo) to German) // doesn't work

…So how does Oni relate to this? Oni is a browser-based “embedded structured concurrency framework”. It allows you to write asynchronous code as if it was synchronous, adding back the kind-of composibility that is lost when juggling concurrent strands of execution (such as e.g. pending XMLHttpRequests) with ‘conventional’ sequential languages.

Related Posts

  1. Ubiquity i18n: questions to ask
  2. Big Issues and Small Issues with Parser 2
  3. Count command for Ubiquity

Related posts brought to you by Yet Another Related Posts Plugin.


Cool Ubiquity Ad Concept

Jono DiCarlo

April 28, 2009

12:42 pm

Speaking of marketing that better explains what Ubiquity does, student contributor Zac Lym has made a really cool Ubiquity ad concept video. I’ve gotten used to taking Ubiquity for granted, but watching this video makes me excited about it again.


Cool Ubiquity Ad Concept

Jono DiCarlo

12:42 pm

Speaking of marketing that better explains what Ubiquity does, student contributor Zac Lym has made a really cool Ubiquity ad concept video. I’ve gotten used to taking Ubiquity for granted, but watching this video makes me excited about it again.


Do We Still Need Bookmarks: Mobile Edition

Jono DiCarlo

10:08 am

I’d like to thank my readers for their comments on my previous post about bookmarks. It was very useful for me to hear about the bookmark use cases that I had overlooked (for instance, I didn’t realize how important the bookmark-all-in-folder / open-folder-in-tabs feature was to so many of you.)

Now I have a follow-up question for you readers. I’m trying to understand how bookmark usage patterns differ on mobile web browsing platforms. This issue has serious implications for the design of the bookmark UI in Fennec. It also affects the design of Weave. What should be the default Weave behavior when syncing bookmarks between desktop and mobile clients? The current behavior is to simply merge the two lists, so you have the same bookmarks in both places. But if there is a big difference between the bookmarks you want on one side and the bookmarks you want on the other side, then maybe pushing everything into one big pile isn’t the best approach.

I must admit that I very rarely do any mobile web-browsing. I have an old, crummy cell phone that I barely use. I take my laptop everywhere and do my web browsing on that. (I know, I’m behind the times.) In fact, the browsing I’ve done on my Nokia N810 in order to develop and test Weave on Fennec is about the most that I’ve done. That means that I have not developed the personal experience or intuition to guide design decisions about mobile browsing. Instead, I have to rely on data, input, and stories from others who do use the mobile web.

Picture of me cursing my cell phone

That’s why, if you are a mobile web user, I am especially interested in your answers to the following questions:

  1. Do you use bookmarks when browsing on a cell phone or other mobile device?
  2. If so, how does your bookmark use on mobile differ from your bookmark use on a desktop or laptop machine?
  3. If you don’t use bookmarks in mobile browsing, why not? Is it because of a poor interface, because your needs are different, or some other reason?
  4. Finally, is there a difference between the set of bookmarks you commonly use on the desktop, and the set of bookmarks you commonly use (or think you would use) on a mobile gadget? Do you think there’s a case for keeping these two lists of bookmarks separate?

Thanks very much for your feedback!


Crash Analysis/Diagnostics of IBM SDKs for WAS Webcast on May 13, 2009

Davanum Srinivas

April 27, 2009

6:49 am

Invite posted on WAS forum:
http://www.ibm.com/developerworks/forums/thread.jspa?threadID=260362&tstart=0
On 13 May 2009 at 11:00 AM EDT, a WebSphere Support Technical Exchange presentation on Crash Analysis/Diagnostics of IBM SDKs (1.5 & 1.6) for WebSphere Application Server will be delivered by Giribabu Paramkusham, Ajay Bhalodia & Daniel Julin, subject matter experts. An open question and answer session will follow [...]


Design Conundrums

Zach

April 26, 2009

2:20 pm

Just did a quick usability test on a friend with the new ad I created. Didn’t go well- nothing changed fundamentally in the user being unable to invoke Ubiquity.
So do I start every sequence with option+spacebar? What about enter?
I will probably just tell what participants what to do since problem will likely go away after the URL bar is integrated.


Ubiquity in Fx Mockup Redux

Zach

April 25, 2009

8:22 pm

This is an extension of an earlier mockup of Ubiquity/URL bar integration, AKA Taskfox. It includes a tab-like design, inline command additions, and command autocomplete.
The main addition is the use of a tab-like format to indicate which command is being presented and hint at arrowing to the other tabs. The overall look could be more minimalist, but it illustrates my point.
I am also less than happy about the visual design for adding a new command (of course, I am never happy with my own work). However, the idea itself, I believe, is very sound. It cuts down on the confusion required by the current add-ons process and adds a layer of error correction/anticipation to the Taskfox.
During the usability studies I saw users randomly type in potential commands. This random guessing is users asking for commands, and we should give it to them. Offering commands in the URL bar and alongside an error/search page offers users a solution at the right time.
Currently, for a user to install a Firefox command they have to either A) know it exists or B) make the effort to find it. It helps explains the 50% of Firefox users who don’t have any add-ons installed and the 14% who don’t know what an add-on is (probably more as survey samples trend towards advanced users).
Lastly, inline offerings of new commands could use the Add-ons repository as a proxy -cutting out annoying security messages and trips to the FF add-ons site.
I also added word/command autocompletion to the URL bar. Normally I hate word autocompletion and apparently so do most OpenOffice users. However, in certain contexts (such as cell phones) some users swear by it. I suspect autocomplete is universally disliked when it distracts from a task without making the task faster. This could be a different scenario for FF as the spacebar seems like a logical step given the examples. Also, people aren’t writing documents here as they do in OpenOffice- in fact Firefox users should be habituated to autocompletion in the URL bar.
On the other hand, devoting two rows of URL suggestion to Taskfox may be more than enough to get users attention, making autocompletion overkill. A combination of eye tracking, usability studies, and maybe even some analytical data by streaming alternate versions of Taskfox to users (one version with autocomplete and one without) to see if adoption rates pick up would quantitatively answer these questions.
I hope everyone likes the mockup. The PSD is here for remixing : )


Older Posts »