- a program to keep track of tasks [a TODO list]
= allow me to add / modify the list, which might be an article, a webpage, a book etc
= allow me to prioritize them
= set a deadline
= somehow a reminder
= can sync with sunbird
- Photo album
= similar to sony's imagestation, yahoo! photo album
Reference:
http://www.imagestation.com
http://photos.yahoo.com
Tuesday, February 07, 2006
Blog What I read: talking about design
Luis Villa wrote:
> On 2/7/06, JP Rosevear wrote:
>> The changes that were implemented were not as radical as the
>> mockups. Basically what Nat F. showed in Paris is what was
>> implemented. The code will be released to the community soon.
>
> To ask the obvious question, why not now, and why not discussed
> publicly earlier?
So here's my (ie, not Novell's) answer.
Two words: "bike shed"[1]. Or actually, "stop energy"[2] works too. Your
pick.
Although the changes aren't nearly as radical as the original mockups,
they are a big change from the current GNOME panel menu. If we had
proposed the changes on the mailing lists, it would have started a huge
discussion about what people hated about the design ("you can't make the
panel menu depend on beagle!!!") and how it should be different. And
then we could have either (a) completely ignored everyone and done it
ourselves anyway, or (b) had a long conversation about the merits of the
design and then not actually finished the code in time for NLD10.
So we did it ourselves, and now either GNOME will like what we did, in
which case, yay, free code for GNOME, or GNOME won't like what we did,
in which case, no harm no foul for GNOME, and yay, brand differentiation
for Novell. (And anyone who yells "fork" deserves to get one stuck in them.)
An equivalent answer to the question is "because you can't do design by
committee". Everything good in GNOME is good because one person or a
small number of people working closely together made it good. Much of
what is bad in GNOME is bad because lots of people have contributed
without having a single vision of what the end result is supposed to be.
I mean, look at the stuff John Williams has been blogging about the last
week[3]:
* Evolution's UI blocking on I/O SUCKS. Due to lack of design in the
early stages of development
* Evolution's integration with gaim and tomboy RULES. Both of these
happened because specific people (ChipX86, orph) made them happen.
* Multimedia integration SUCKS. No one has ever sat down and tried
to fix the big picture. (Although I think the gstreamer team is in
the process of doing this now?)
* Apps not remembering their window size and position SUCKS. Again,
needs someone to take this problem and make it their own. I
remember xkahn was trying to fix this a few years ago, but never
finished.
* Bug-buddy SUCKS. Jacob's original UI was simple and brilliant. But
as more and more people added more and more features without
looking at the big picture, it got unwieldy. (But now a small
team is putting the simplicity back in again.)
* Deskbar applet RULES (kikidonk), dashboard RULES (Nat), and beagle
RULES (trow and joe). None of these was done *exclusively* by
those people, but each of them reflects one person's (or a few
people's) vision, as opposed to the current state of bug buddy,
which just sort of happened.
This is just another aspect of the UI "simplicity" thing. We like UIs
that try to do the right thing (metacity, epiphany/firefox, evince)
rather than UIs that try to make every possible user happy
(enlightenment, mozilla, gpdf/acroread). If you try to design something
by committee, you either have to end up with the latter sort of messy
does-everything UI, or you ignore and hence piss off a large chunk of
the committee.
And that's where we are with NLD. There is no way that everyone in the
GNOME community is going to like the changes we wanted to make. But we
did the user testing, and we believe in it, and we want to make the
changes anyway. So we're doing it. Maybe it will turn out good, and
maybe it will turn out bad. Either way, the GNOME community learns from
it. Think of it like this: wouldn't it have been cool if we could have
tried out spatialus on our users, found out that they hated it, and then
reverted back to browserlus, without ever having to actually piss off
our users? This is essentially what is going to happen with NLD10. If
Novell's customers like the NLD changes, then GNOME can adopt them. If
Novell's customers don't like the changes, then GNOME can stand off to
the side and say "yeah well, we never liked that UI anyway. Not at all
like how we would have done it." :-)
But some people will still say "But couldn't you have discussed it with
the community before doing it?" No, we couldn't. If we had, it would
either not have happened, or it would have sucked. It's inevitable. It's
not a problem with the GNOME community, it's a problem with communities
in general. The wisdom of crowds[4] only works in situations where there
are clear right and wrong answers. If you try to apply it to a design
problem, where there are many entirely different right answers, then you
end up with a wrong answer. Always[5].
So to sum up: design by committee is bad, endless debates that result in
code not actually being written are bad, design by very small teams is
good, software with a unified vision is good, trying out cool new UI
ideas is good, free code at least doesn't suck, and of course, for
Novell, not shipping NLD10 is bad. I don't think there's anything we
could have done to get more of the good without also getting more of the
bad.
-- Dan
> On 2/7/06, JP Rosevear
>> The changes that were implemented were not as radical as the
>> mockups. Basically what Nat F. showed in Paris is what was
>> implemented. The code will be released to the community soon.
>
> To ask the obvious question, why not now, and why not discussed
> publicly earlier?
So here's my (ie, not Novell's) answer.
Two words: "bike shed"[1]. Or actually, "stop energy"[2] works too. Your
pick.
Although the changes aren't nearly as radical as the original mockups,
they are a big change from the current GNOME panel menu. If we had
proposed the changes on the mailing lists, it would have started a huge
discussion about what people hated about the design ("you can't make the
panel menu depend on beagle!!!") and how it should be different. And
then we could have either (a) completely ignored everyone and done it
ourselves anyway, or (b) had a long conversation about the merits of the
design and then not actually finished the code in time for NLD10.
So we did it ourselves, and now either GNOME will like what we did, in
which case, yay, free code for GNOME, or GNOME won't like what we did,
in which case, no harm no foul for GNOME, and yay, brand differentiation
for Novell. (And anyone who yells "fork" deserves to get one stuck in them.)
An equivalent answer to the question is "because you can't do design by
committee". Everything good in GNOME is good because one person or a
small number of people working closely together made it good. Much of
what is bad in GNOME is bad because lots of people have contributed
without having a single vision of what the end result is supposed to be.
I mean, look at the stuff John Williams has been blogging about the last
week[3]:
* Evolution's UI blocking on I/O SUCKS. Due to lack of design in the
early stages of development
* Evolution's integration with gaim and tomboy RULES. Both of these
happened because specific people (ChipX86, orph) made them happen.
* Multimedia integration SUCKS. No one has ever sat down and tried
to fix the big picture. (Although I think the gstreamer team is in
the process of doing this now?)
* Apps not remembering their window size and position SUCKS. Again,
needs someone to take this problem and make it their own. I
remember xkahn was trying to fix this a few years ago, but never
finished.
* Bug-buddy SUCKS. Jacob's original UI was simple and brilliant. But
as more and more people added more and more features without
looking at the big picture, it got unwieldy. (But now a small
team is putting the simplicity back in again.)
* Deskbar applet RULES (kikidonk), dashboard RULES (Nat), and beagle
RULES (trow and joe). None of these was done *exclusively* by
those people, but each of them reflects one person's (or a few
people's) vision, as opposed to the current state of bug buddy,
which just sort of happened.
This is just another aspect of the UI "simplicity" thing. We like UIs
that try to do the right thing (metacity, epiphany/firefox, evince)
rather than UIs that try to make every possible user happy
(enlightenment, mozilla, gpdf/acroread). If you try to design something
by committee, you either have to end up with the latter sort of messy
does-everything UI, or you ignore and hence piss off a large chunk of
the committee.
And that's where we are with NLD. There is no way that everyone in the
GNOME community is going to like the changes we wanted to make. But we
did the user testing, and we believe in it, and we want to make the
changes anyway. So we're doing it. Maybe it will turn out good, and
maybe it will turn out bad. Either way, the GNOME community learns from
it. Think of it like this: wouldn't it have been cool if we could have
tried out spatialus on our users, found out that they hated it, and then
reverted back to browserlus, without ever having to actually piss off
our users? This is essentially what is going to happen with NLD10. If
Novell's customers like the NLD changes, then GNOME can adopt them. If
Novell's customers don't like the changes, then GNOME can stand off to
the side and say "yeah well, we never liked that UI anyway. Not at all
like how we would have done it." :-)
But some people will still say "But couldn't you have discussed it with
the community before doing it?" No, we couldn't. If we had, it would
either not have happened, or it would have sucked. It's inevitable. It's
not a problem with the GNOME community, it's a problem with communities
in general. The wisdom of crowds[4] only works in situations where there
are clear right and wrong answers. If you try to apply it to a design
problem, where there are many entirely different right answers, then you
end up with a wrong answer. Always[5].
So to sum up: design by committee is bad, endless debates that result in
code not actually being written are bad, design by very small teams is
good, software with a unified vision is good, trying out cool new UI
ideas is good, free code at least doesn't suck, and of course, for
Novell, not shipping NLD10 is bad. I don't think there's anything we
could have done to get more of the good without also getting more of the
bad.
-- Dan
Sunday, February 05, 2006
Chinese input as if I were in Windows
Finally, get one solution. I like the English UI as I feel it is weird if the interface in Linux is displayed as chinese.
The following contains the text for reference only. The original page is:
http://www.mrbass.org/linux/ubuntu/scim/
Ubuntu CJK Chinese Japanese Korean Input Guide
Ubuntu 5.04 Hoary SCIM Chinese, Japanese, and Korean Input Guide
You can install CJK input via ubuntuaddon or do it via internet.
Ubuntu already comes with Chinese, Japanese and Korean fonts preinstalled.
To install via internet (universe repositories must be enabled)
sudo apt-get install uim anthy scim-gtk2-immodule scim-uim scim-chinese scim-hangul scim-tables-zh scim-tables-ja scim-tables-ko
Add SCIM to startup for X11
sudo touch /etc/X11/Xsession.d/74custom-scim_startup
sudo chmod 646 /etc/X11/Xsession.d/74custom-scim_startup
echo 'export XMODIFIERS="@im=SCIM"' >> /etc/X11/Xsession.d/74custom-scim_startup
echo 'export GTK_IM_MODULE="scim"' >> /etc/X11/Xsession.d/74custom-scim_startup
echo 'export XIM_PROGRAM="scim -d"' >> /etc/X11/Xsession.d/74custom-scim_startup
echo 'export QT_IM_MODULE="scim"' >> /etc/X11/Xsession.d/74custom-scim_startup
sudo chmod 644 /etc/X11/Xsession.d/74custom-scim_startup
Press CTRL-SPACE to bring up SCIM input methods.
Next two steps are OPTIONAL (scim KDE startup and input KDE apps while in GNOME)
If you installed kubuntu-desktop (KDE) and plan on logging into KDE session do this in terminal
sudo touch ~/.kde/Autostart/startscim
echo '"#!/bin/sh"' >> ~/.kde/Autostart/startscim
echo "scim -d" >> ~/.kde/Autostart/startscim
sudo chmod 745 ~/.kde/Autostart/startscim
While using GNOME:
you can input into GNOME, GTK apps but NOT KDE apps.
While using KDE you can input GNOME, GTK and KDE apps.
So if you want to also input in KDE apps while using GNOME do the following:
sudo touch ~/.gnome2/session-manual
echo "[Default]" >> ~/.gnome2/session-manual
echo "num_clients=1" >> ~/.gnome2/session-manual
echo "0,RestartStyleHint=3" >> ~/.gnome2/session-manual
echo "0,Priority=50" >> ~/.gnome2/session-manual
echo "0,RestartCommand=scim -d" >> ~/.gnome2/session-manual
echo "0,Program=scim" >> ~/.gnome2/session-manual
This will create two SCIM keyboards under GNOME though but allows you to input in KDE apps while in GNOME.
The following contains the text for reference only. The original page is:
http://www.mrbass.org/linux/ubuntu/scim/
Ubuntu CJK Chinese Japanese Korean Input Guide
Ubuntu 5.04 Hoary SCIM Chinese, Japanese, and Korean Input Guide
You can install CJK input via ubuntuaddon or do it via internet.
Ubuntu already comes with Chinese, Japanese and Korean fonts preinstalled.
To install via internet (universe repositories must be enabled)
sudo apt-get install uim anthy scim-gtk2-immodule scim-uim scim-chinese scim-hangul scim-tables-zh scim-tables-ja scim-tables-ko
Add SCIM to startup for X11
sudo touch /etc/X11/Xsession.d/74custom-scim_startup
sudo chmod 646 /etc/X11/Xsession.d/74custom-scim_startup
echo 'export XMODIFIERS="@im=SCIM"' >> /etc/X11/Xsession.d/74custom-scim_startup
echo 'export GTK_IM_MODULE="scim"' >> /etc/X11/Xsession.d/74custom-scim_startup
echo 'export XIM_PROGRAM="scim -d"' >> /etc/X11/Xsession.d/74custom-scim_startup
echo 'export QT_IM_MODULE="scim"' >> /etc/X11/Xsession.d/74custom-scim_startup
sudo chmod 644 /etc/X11/Xsession.d/74custom-scim_startup
Press CTRL-SPACE to bring up SCIM input methods.
Next two steps are OPTIONAL (scim KDE startup and input KDE apps while in GNOME)
If you installed kubuntu-desktop (KDE) and plan on logging into KDE session do this in terminal
sudo touch ~/.kde/Autostart/startscim
echo '"#!/bin/sh"' >> ~/.kde/Autostart/startscim
echo "scim -d" >> ~/.kde/Autostart/startscim
sudo chmod 745 ~/.kde/Autostart/startscim
While using GNOME:
you can input into GNOME, GTK apps but NOT KDE apps.
While using KDE you can input GNOME, GTK and KDE apps.
So if you want to also input in KDE apps while using GNOME do the following:
sudo touch ~/.gnome2/session-manual
echo "[Default]" >> ~/.gnome2/session-manual
echo "num_clients=1" >> ~/.gnome2/session-manual
echo "0,RestartStyleHint=3" >> ~/.gnome2/session-manual
echo "0,Priority=50" >> ~/.gnome2/session-manual
echo "0,RestartCommand=scim -d" >> ~/.gnome2/session-manual
echo "0,Program=scim" >> ~/.gnome2/session-manual
This will create two SCIM keyboards under GNOME though but allows you to input in KDE apps while in GNOME.
Thursday, February 02, 2006
Oh. yes, nearly forget this blog...
These days need to prepare the documentation for hmm project. We are going to abort this project because it is really quite time consuming and the requirement always changes without control.
The following is a brief architecture overview of hmm project:
The following is a brief architecture overview of hmm project:
Subscribe to:
Posts (Atom)
