I hope you have noticed banner above saying that I have moved my blog. Finally I decided to do that as I was really unhappy using this page. So from now on my posts can be found on http://rfobic.wordpress.com
P.S.: History has been moved as well, so if you want to add some comment please do it on the link above, as I'm not going to check the comments on this page anymore !!
Moved !!!
2009-02-20
2009-02-18
Some Mock-up around Ubiquity
In this post I am planing to talk about new Ubiquity command I'm working on currently and share some of my thought about:
Not a long time ago I realized that I've posted about several ubiquity commands I have developed, but I never tried to share my opinion about the project in general, so I'm going to do it now. I think that Ubiquity is just Incredible way to increase usability of the browser from the one hand and usability of web services from the other hand. Another reason why Ubiquity is a really cool project is an API. Developers are able to write almost quite complex commands keeping the process amazingly simple. I'm pretty sure that one hour playing with ubiquity is quite enough for any web developer to start writing own commands. Besides wiki has a nice tutorial to get you up to speed.
Before I will start talking about difficulties I've faced, I will describe briefly the command itself.
Well actually it's not just a command, it's a set of commands for working with Bugzilla. As you might know Bugzilla has standard API for external programs that want to interact with it. Methods can be accessed via XML-RPC. So basically I tried to write Bugzilla client on top of Ubiquity. Currently commands are under the heavy development so there's not much functionality there yet, but in case if you'd like to test it or you want to look at the source you're able to do it here >> http://gist.github.com/65354
You might already guessed that the command will be quite complex one. Actually that one of the issues I've faced. While it's really simple to develop small commands, it becomes almost impossible to work on complex ones. By the small commands I mean commands which are performing one / two tasks, and accepts only one / two modifiers. To give a better understanding what I mean I will try to write some user cases.
Possible solution would be to add all of the modifiers to the get command but the bad thing about it is that then you have to calculate which modifiers have been passed and guess based on that what user meant to get info for a user or for a bug. We should keep in mind that we can confuse users that way as well as they will see all this possible modifiers. One disadvantage is that lets suppose user is confused and have typed something like:
get 156 me@email.com is user trying to find a bug or user? Well he's confused we can manage to find it out but in that case we have to add extra parsing of the user input
one more example
get bug 156* username me is user still looking for a bug or user should we suggest bugs with numbers starting with 156 or users with the names me or both ?
Obviously adding all of the modifiers is a bad solution cause in real life example it's much more complex cause you can get bug by: assignees, reporters, resolution, by report date, by target os and many more modifiers. and it's actually the same with user a user. Even worse some of them can have same modifires like user_id so if you search by assignees you're passing the user_id and you can do the same if you're looking for the users with the user_id. Sure it's possible to identify them with different names but for a complex commands it still a nightmare, and no way simple to use for end users.
Well there's another solution to use different names for actions, actually that what usually ubiquity command developers do (From what I noticed), but unfortunately here is a limitation as we can't use space separated names for actions. So the solution is to have two commands get-user and get-bug in this case most of the problems are solved but in this case it's not really natural. Unfortunately that's not acceptable as well because even this names are quite common a lot of commands can have action like get-user so in order to tide action to a target we must do something like bugzilla-get-user, bugzilla-get-bug, with each step it becomes less and less natural :(. I have to say that in case of Bugzilla command[s] it's far from the reality, you still need more and more dashes.
I was thinking about alternative solution, how to keep things more natural how to scope command sets in one namespace. I think it could be done through dynamic modifiers. I mean modifiers which can have their own modifiers. What I mean is that based on input modifier should be able to ask for some more details / more modifiers.
Lets take a look at the flow below, suppouse I am asking some person called ubiquity to do something.
I really hope you don't imagine that you have to type all this in the command line :)
Lets take a look at the same flow but if we were doing that with the commind line
What are the advantages of this kind of architecture:
- Ubiquity in general.
- Problems I've faced during development.
- Ideas how to improve
Not a long time ago I realized that I've posted about several ubiquity commands I have developed, but I never tried to share my opinion about the project in general, so I'm going to do it now. I think that Ubiquity is just Incredible way to increase usability of the browser from the one hand and usability of web services from the other hand. Another reason why Ubiquity is a really cool project is an API. Developers are able to write almost quite complex commands keeping the process amazingly simple. I'm pretty sure that one hour playing with ubiquity is quite enough for any web developer to start writing own commands. Besides wiki has a nice tutorial to get you up to speed.
Before I will start talking about difficulties I've faced, I will describe briefly the command itself.
Well actually it's not just a command, it's a set of commands for working with Bugzilla. As you might know Bugzilla has standard API for external programs that want to interact with it. Methods can be accessed via XML-RPC. So basically I tried to write Bugzilla client on top of Ubiquity. Currently commands are under the heavy development so there's not much functionality there yet, but in case if you'd like to test it or you want to look at the source you're able to do it here >> http://gist.github.com/65354
You might already guessed that the command will be quite complex one. Actually that one of the issues I've faced. While it's really simple to develop small commands, it becomes almost impossible to work on complex ones. By the small commands I mean commands which are performing one / two tasks, and accepts only one / two modifiers. To give a better understanding what I mean I will try to write some user cases.
- As a user I would like to have one command to perform all the tasks used during work-flow.
What I mean is that command should have kind of namespace? or something like a topic which you are comunnicating with ubiquity with. It should be kind of keyword to describe the target against what my actions are performed. - I want to have a set of verbs to describe what actions I am going to perform against the target
- I want to have modifires to describe what exactly the actions should do with the target.
- To keep simplicity of use I would expect that ubiquity will remember whatever I was talking about. I mean I don't like to describe all the details (modifires) in every sentence I'm writing. For example: when I am talking with a person about a bug in firefox, which occurs only on Linux, I don't repeat in the same details in each sentence during talk,
I don't say that :
I have added the comment to the bug in firefox, which occurs only on Linux, that I was not able to reproduce it.
I would rather say :
I have added the comment to the bug that I was not able to reproduce it"
As I expect that person I'm talking with still remembers what I was talking about in a previous sentence.
- I'd like to get information about bug in bugzilla system. (There can be several bugzilla systems like one from mozilla one from kde ...)
- I'd like to be able to store my sessions the way I'll be able to simply identify the origin of the bug I'm talking. I mean which bugzilla system is it coming from which.
- comment on the bug with some useful information (again in particular bugzilla session )
- I'd like to get information about user (can get user by username, email ) again in particular bugzilla session )
- actions : get, comment
- actual data : information
- modifires : bug, session, user, username, email
Possible solution would be to add all of the modifiers to the get command but the bad thing about it is that then you have to calculate which modifiers have been passed and guess based on that what user meant to get info for a user or for a bug. We should keep in mind that we can confuse users that way as well as they will see all this possible modifiers. One disadvantage is that lets suppose user is confused and have typed something like:
get 156 me@email.com is user trying to find a bug or user? Well he's confused we can manage to find it out but in that case we have to add extra parsing of the user input
one more example
get bug 156* username me is user still looking for a bug or user should we suggest bugs with numbers starting with 156 or users with the names me or both ?
Obviously adding all of the modifiers is a bad solution cause in real life example it's much more complex cause you can get bug by: assignees, reporters, resolution, by report date, by target os and many more modifiers. and it's actually the same with user a user. Even worse some of them can have same modifires like user_id so if you search by assignees you're passing the user_id and you can do the same if you're looking for the users with the user_id. Sure it's possible to identify them with different names but for a complex commands it still a nightmare, and no way simple to use for end users.
Well there's another solution to use different names for actions, actually that what usually ubiquity command developers do (From what I noticed), but unfortunately here is a limitation as we can't use space separated names for actions. So the solution is to have two commands get-user and get-bug in this case most of the problems are solved but in this case it's not really natural. Unfortunately that's not acceptable as well because even this names are quite common a lot of commands can have action like get-user so in order to tide action to a target we must do something like bugzilla-get-user, bugzilla-get-bug, with each step it becomes less and less natural :(. I have to say that in case of Bugzilla command[s] it's far from the reality, you still need more and more dashes.
I was thinking about alternative solution, how to keep things more natural how to scope command sets in one namespace. I think it could be done through dynamic modifiers. I mean modifiers which can have their own modifiers. What I mean is that based on input modifier should be able to ask for some more details / more modifiers.
Lets take a look at the flow below, suppouse I am asking some person called ubiquity to do something.
- me: Can you please make a comment to a bug ?
- ubiquity: What should be the text ? (Asks input for comment)
- me: "I'm not able to reproduce it"
- ubiquity: Suppose you're mean bug 146 or might be its one from 846, 400, 8942 (assumes that I'm talking about the bug I mentioned last time, but also suggests me some other bugs we've talked recently)
- me: bug 846
- ubiquity: so you mean bug 846 in mozilla (verifyes that I am talking about mozilla bugs as we talked about them last time)
- me: and attach screenshot please
- ubiquity: dou you like this one ??
- me: perfect
I really hope you don't imagine that you have to type all this in the command line :)
Lets take a look at the same flow but if we were doing that with the commind line
- bugzilla connect
I started typeing "bugzilla co" as there are two actions (1. connect 2. comment) targeting bugzilla command ubiquity completes input with "bugzilla connect" because connect was used more recently. At the same time ubiquity selects auto-completed part to allow user go on with typing, it as well adds "comment" action to the suggestions.
in case if I press button:- right arrow / enter / tab
in this case ubiquity will request / verify next modifier (there will be more details in the next slides) - down arrow
in this case we'll have picture described in the 2nd list item.
- right arrow / enter / tab
- bugzilla comment (text)
ubiquity will autocomlete word "comment" and will show that it expects text input by adding and selecting "(text)" in case of having selected text in the browser selection will be inserted and selected instead, if there is some data in the clipboard as well it will be suggested as an input through suggestions
in case if I:- I will stop typing / will make delay
in this case we'll have picture described in the 3nd list item. - will press button right arrow / enter / tab
in this case we'll have picture described in the 3nd list item. - will press button left arrow
action "comment" will be selected and the other bugzilla targeted actions will be suggested. In the preview help for the comment function will appear. in case of choosing other action all the following modifiers will disappear. - will press down arrow
in case of having suggestions will switch input data according to the suggestions
- I will stop typing / will make delay
- bugzilla comment " I'm not able to reproduce it" on a bug 146
Ubiquity auto-completes with "on a bug 146" ("on a bug" is a prefix for modifier-bug). Selecting "146" as it's a modifier-bug accessed most recently, ubiquity verifies that I'm still interacting with it, at the same time it still gives me ability to type the id manually. It adds other bugs into suggestions 846, 400, 8942 as they've been recently used. Ubiquity suggests everything it has in history as the whole modifier is selected in this case. In the preview information for the currently selected bug (146) is shown.
in case if I press button:- 8
Ubiquity will auto-complete it with "46" (as it's was accessed more recently then 8942) and will select auto-completed part (46). In the suggestions only 8942 will show up as it's an only matching bug id from the history. In the preview information for the currently selected bug (846) is shown. - right arrow / enter / tab
in this case ubiquity will request / verify next modifier - down arrow
in this case we'll have picture described in the 4th list item (as the first suggestion is 846). - left arrow
input " I'm not able to reproduce it" will be selected in case of having selection, clipboard data they will be suggested.
- 8
- bugzilla comment " I'm not able to reproduce it" on a bug 846 in session mozilla
Ubiquity auto-completes with "in the session mozilla" ("in the session " is prefix for modifier-session). Ubiquity verifies that it needs to use mozilla as modifier-session as it was used most recently. It also adds all the available sessions in suggestions cause whole modifier is selected. (kde, eclipse) At the same time in preview it shows info for mozilla session. (user, url)
in case if I press button:- e
Ubiquity will auto-complete it with "eclipse" (it's wasn't accessed more recently then kde but it allows to go on typing unlike "kde") and will select auto-completed part ("clipse"). In the suggestions only "kde" will show up as it's an only matching session. In the preview information for the currently selected session (eclipse) is shown. - right arrow / tab
in this case ubiquity will put cursor in the end of the line and will show all possible (optional) modifiers in the suggestion. - down arrow
will select "kde" as a session and will select only matching part of it "e" - left arrow
modifier-bug "846" will be selected in all possible suggestions will be suggested. - enter
Will add a comment to the bug
- e
- bugzilla comment " I'm not able to reproduce it" on a bug 846 and attach (data)
I have typed at as I wanted to attach file with a comment. Ubiquity did not suggested attach-modifier as it's an optional. but when I type "at", it auto-completes it with "and attach (data)" where "and attach " is a prefix for the attach-modifier. "(data)" got selected. Ubiquity suggests clipboard, screen-shot in the suggestions as that are the magic words which attach-modifier can take as an input.
What are the advantages of this kind of architecture:
- All the commands performing the actions against one target can be scoped by the namespace. Actually it can be a one command.
- Command Modifiers can have their own modifiers, that makes it possible to create better abstraction layer of the services on top of the Ubiquity.
- Modifiers have are ordered in a logical way, and some of them can be optional, value of one modifier can automatically make useless use of another modifier.
- Makes commands more closer to the natural language, cause in this model modifier is modeled as a sentence. Use of prefixes, suffixes makes it much easier to represent in more human way (it's even more important in some languages where suffix / prefix can change whole meaning of the sentence)
- Modifier is having step by step dialog with a user, keeping user focused more on the step rather on the end result.
- Asks user for input only in case if there is no other way
- User types only the data no modifier names.
- Ubiquity uses history to make discussion more intuitive. (Actually it's possible to do it even now through commands but think it might have a sense to expose this functionality some in some standard manner to the developers)
2009-02-01
Mozshell
In this post I am going to write about one of my projects, which I presented at FOSDEM, during Mozilla lightning talks. Unfortunately I had not enough time to give a good idea what what is MozShell and what potential it has...
For several years already, I'm working with XUL and JavaScript in differnt companies and different applications. I think every extension / xulrunner developers will agree that there are no reliable tools for our hard job, what makes development process slower and more complicated. Well there are tools like Venkman and Chrome bug, but if you can can make them work on Firefox, you will never manage to make them work properly on other third party XULRunner based applications. Even if you will it's quite different from having well integrated tool into your primary editor. So that's how I got inspired to write an extension for Komodo Edit which add's JavaScript shell and Object inspector to the editor. It is not just another js shell among hundreds of others. It is quite unique with its architecture and really interesting features. MozShell is focused on xulrunner / extension developers, it gives ability to create remote connections to (any xulrunner based) applications, no meter if they are running on the local machine, or different remote, or even virtual machines. You can evaluate JavaScript during run-time, Inspect Objects, etc.. Because of the name some people might confused, integration with an editor makes it completely different from what we call shell but at the same time experimental interface makes it much easier and fast to use.
Extension is still on the very early stage of development but still you can gibe it a try and give some feedback!!
Project of caurse is an open source and can be found here.
For several years already, I'm working with XUL and JavaScript in differnt companies and different applications. I think every extension / xulrunner developers will agree that there are no reliable tools for our hard job, what makes development process slower and more complicated. Well there are tools like Venkman and Chrome bug, but if you can can make them work on Firefox, you will never manage to make them work properly on other third party XULRunner based applications. Even if you will it's quite different from having well integrated tool into your primary editor. So that's how I got inspired to write an extension for Komodo Edit which add's JavaScript shell and Object inspector to the editor. It is not just another js shell among hundreds of others. It is quite unique with its architecture and really interesting features. MozShell is focused on xulrunner / extension developers, it gives ability to create remote connections to (any xulrunner based) applications, no meter if they are running on the local machine, or different remote, or even virtual machines. You can evaluate JavaScript during run-time, Inspect Objects, etc.. Because of the name some people might confused, integration with an editor makes it completely different from what we call shell but at the same time experimental interface makes it much easier and fast to use.
Extension is still on the very early stage of development but still you can gibe it a try and give some feedback!!
Project of caurse is an open source and can be found here.
Subscribe to:
Posts (Atom)
