http://wiki.openmoko.org/api.php?action=feedcontributions&user=Pike&feedformat=atomOpenmoko - User contributions [en]2013-05-25T12:19:57ZUser contributionsMediaWiki 1.19.6http://wiki.openmoko.org/wiki/User:Pike/ThoneUser:Pike/Thone2010-06-16T21:32:29Z<p>Pike: </p>
<hr />
<div>=Thone - a Terminal Phone =<br />
<br />
'''Thone is a terminal phone written in Bash3 and python for FSO based devices.'''<br />
<br />
----<br />
Note: FSO has changed its interfaces and at least sms is not working anymore. I'm working on it, as time permits ..<br />
----<br />
<br />
[[Image:Thone-example.jpg |left|thumb]]<br />
<br />
<br />
More precise, thone is a suite of bash scripts to operate your daily phone: sms, call, etc. It does not yet handle dbus signals, such as incoming calls, incoming messages or even outgoing calls; these should still be handled by your default software.<br />
<br />
I'm maintaining it here: http://code.google.com/p/thone<br />
<br />
It requires<br />
* a linux based phone like openmoko<br />
* running on FSO and with the python/dbus library<br />
* with bash3 installed<br />
<br />
Running 'thone' starts a new (bash) shell and initializes Thone. <br />
In that shell, you have additional commands like <br />
<br />
> call +310652252252<br />
> ppl add +31065225222 frank<br />
> sms @frank answer your damn phone, i know youre there<br />
> toggle sleep on<br />
<br />
.. and autocompletion is your friend.<br />
<br />
I'm using it on my Openmoko on SHR-U. It comes with a launcher icon for Enlightenment, which spawns a big fonted Vala-terminal with 'thone jail' in it - so for example "sms read" looks like the image above.</div>Pikehttp://wiki.openmoko.org/wiki/Talk:Create_an_ipk_package_from_sourcesTalk:Create an ipk package from sources2010-04-01T22:21:04Z<p>Pike: New page: =Suggestions= Not knowing anything about bitbake and ipkg, I found this page pretty confusing. it should mention what ipkg is to start with. And link to http://www.handhelds.org/moin/moi...</p>
<hr />
<div>=Suggestions=<br />
<br />
Not knowing anything about bitbake and ipkg, I found this page pretty confusing. <br />
it should mention what ipkg is to start with. And link to http://www.handhelds.org/moin/moin.cgi/Ipkg<br />
<br />
I stopped reading several times at "Prerequisites - You need a configured openmoko development tree."<br />
Is that true ? Do you need that to "Create an ipk package from sources" ?<br />
<br />
I'm guessing the directions on http://www.handhelds.org/moin/moin.cgi/BuildingIpkgs work just fine for openmoko; that link is also used on http://wiki.openmoko.org/wiki/Opkg<br />
<br />
Most of this page is about writing bitbake recipes to create ipkgs. If I understand correctly, this is needed to get the ipkg creation into your compile process. If I'm correct, then the page should be renamed. And I shouldn't have been reading it in the first place :-)<br />
<br />
<br />
--[[User:Pike|pike]] 22:21, 1 April 2010 (UTC)</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/ThoneUser:Pike/Thone2010-03-30T23:52:58Z<p>Pike: /* Thone - a Terminal Phone */</p>
<hr />
<div>=Thone - a Terminal Phone =<br />
<br />
'''Thone is a terminal phone written in Bash3 and python for FSO based devices.'''<br />
<br />
[[Image:Thone-example.jpg |left|thumb]]<br />
<br />
<br />
More precise, thone is a suite of bash scripts to operate your daily phone: sms, call, etc. It does not yet handle dbus signals, such as incoming calls, incoming messages or even outgoing calls; these should still be handled by your default software.<br />
<br />
I'm maintaining it here: http://code.google.com/p/thone<br />
<br />
<br />
It requires<br />
* a linux based phone like openmoko<br />
* running on FSO and with the python/dbus library<br />
* with bash3 installed<br />
<br />
Running 'thone' starts a new (bash) shell and initializes Thone. <br />
In that shell, you have additional commands like <br />
<br />
> call +310652252252<br />
> ppl add +31065225222 frank<br />
> sms @frank answer your damn phone, i know youre there<br />
> toggle sleep on<br />
<br />
.. and autocompletion is your friend.<br />
<br />
I'm using it on my Openmoko on SHR-U. It comes with a launcher icon for Enlightenment, which spawns a big fonted Vala-terminal with 'thone jail' in it - so for example "sms read" looks like the image above.</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/ThoneUser:Pike/Thone2010-03-30T23:48:24Z<p>Pike: /* Thone - a Terminal Phone */</p>
<hr />
<div>=Thone - a Terminal Phone =<br />
<br />
'''Thone is a terminal phone written in Bash3 and python for FSO based devices.'''<br />
<br />
[[Image:Thone-example.jpg |left|thumb]]<br />
<br />
<br />
More precise, thone is a suite of bash scripts to operate your daily phone: sms, call, etc. It does not yet handle dbus signals, such as incoming calls, incoming messages or even outgoing calls; these should still be handled by your default software.<br />
<br />
I'm maintaining it here: http://code.google.com/p/thone<br />
<br />
<br />
It requires<br />
* a linux based phone like openmoko<br />
* running on FSO and with the python/dbus library<br />
* with bash3 installed<br />
<br />
Running 'thone' starts a new (bash) shell and initializes Thone. <br />
In that shell, you have additional commands like <br />
<br />
> call +310652252252<br />
> ppl add +31065225222 frank<br />
> sms @frank answer your damn phone, i know youre there<br />
> toggle sleep on<br />
<br />
.. and autocompletion is your friend.<br />
<br />
I'm using it on my Openmoko on SHR-U. It comes with a launcher icon for Enlightenment, which spawns Vala-terminal with 'thone jail' in it - so for example "sms read" looks like the image above.</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/ThoneUser:Pike/Thone2010-03-30T23:48:03Z<p>Pike: /* Thone - a Terminal Phone */</p>
<hr />
<div>=Thone - a Terminal Phone =<br />
<br />
'''Thone is a terminal phone written in Bash3 and python for freesmartphonebased devices.'''<br />
<br />
[[Image:Thone-example.jpg |left|thumb]]<br />
<br />
<br />
More precise, thone is a suite of bash scripts to operate your daily phone: sms, call, etc. It does not yet handle dbus signals, such as incoming calls, incoming messages or even outgoing calls; these should still be handled by your default software.<br />
<br />
I'm maintaining it here: http://code.google.com/p/thone<br />
<br />
<br />
It requires<br />
* a linux based phone like openmoko<br />
* running on FSO and with the python/dbus library<br />
* with bash3 installed<br />
<br />
Running 'thone' starts a new (bash) shell and initializes Thone. <br />
In that shell, you have additional commands like <br />
<br />
> call +310652252252<br />
> ppl add +31065225222 frank<br />
> sms @frank answer your damn phone, i know youre there<br />
> toggle sleep on<br />
<br />
.. and autocompletion is your friend.<br />
<br />
I'm using it on my Openmoko on SHR-U. It comes with a launcher icon for Enlightenment, which spawns Vala-terminal with 'thone jail' in it - so for example "sms read" looks like the image above.</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/ThoneUser:Pike/Thone2010-03-30T23:47:14Z<p>Pike: New page: =Thone - a Terminal Phone = '''Thone is a terminal phone written in Bash3 and python for freesmartphonebased devices.''' thumb More precise, thone is ...</p>
<hr />
<div>=Thone - a Terminal Phone =<br />
<br />
'''Thone is a terminal phone written in Bash3 and python for freesmartphonebased devices.'''<br />
<br />
[[Image:Thone-example.jpg |left|thumb]]<br />
<br />
<br />
More precise, thone is a suite of bash scripts to operate your daily phone: sms, call, etc. It does not yet handle dbus signals, such as incoming calls, incoming messages or even outgoing calls; these should still be handled by your default software.<br />
<br />
I'm maintaining it here: http://code.google.com/p/thone<br />
<br />
<br />
It requires<br />
* a linux based phone like openmoko<br />
* running on FSO and with the python/dbus library<br />
* with bash3 installed<br />
<br />
Running 'thone' starts a new (bash) shell and initializes Thone. <br />
In that shell, you have additional commands like <br />
<br />
> call +310652252252<br />
> ppl add +31065225222 frank<br />
> sms @frank answer your damn phone, i know youre there<br />
> toggle sleep on<br />
<br />
.. and autocompletion is your friend.<br />
<br />
I'm using it on my Openmoko on SHR-U. It comes with a launcher icon for Enlightenment, which spawns Vala-terminal with 'thone jail' in it - so for example "sms read" looks like this:</div>Pikehttp://wiki.openmoko.org/wiki/File:Thone-example.jpgFile:Thone-example.jpg2010-03-30T23:42:56Z<p>Pike: An example of running 'sms read' in thone on SHR-U</p>
<hr />
<div>An example of running 'sms read' in thone on SHR-U</div>Pikehttp://wiki.openmoko.org/wiki/User:PikeUser:Pike2010-03-30T23:38:21Z<p>Pike: </p>
<hr />
<div>I just happen to have an openmoko as my main and only phone. So whatever's worth sharing to improve it, I'll add here.<br />
<br />
* [[/OM2009 first run]] use case dd 2009/05/16<br />
* [[/Boring at best]] working on a basic paroli cleanup .. for fun<br />
* [[/Navit]] my Navit customisations<br />
* [[/Shell tools]] some shell tools I keep around<br />
* [[/Thone]] a Terminal Phone<br />
* [[/Open wifi]] my open wifi setup (at home)<br />
* [[/FFShell]] playing with FatFingerShell</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/FFShellUser:Pike/FFShell2009-09-23T15:58:57Z<p>Pike: </p>
<hr />
<div>=Playing with FatFingerShell=<br />
<br />
http://www.youtube.com/watch?v=DV4p414_VJM<br />
<br />
http://fz.hobby-site.org/om/fatfingershell/<br />
<br />
[[Image:Om-template-ffv.png|thumb|left|200px|vertical layout]]<br />
[[Image:Ffshell-neo-h.png|thumb|center|200px|horizontal layout]]</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/FFShellUser:Pike/FFShell2009-09-16T00:11:11Z<p>Pike: </p>
<hr />
<div>=Playing with FatFingerShell=<br />
<br />
http://www.youtube.com/watch?v=DV4p414_VJM<br />
<br />
http://fz.hobby-site.org/om/fatfingershell/<br />
<br />
[[Image:Om-template-ffv.png|thumb|left|200px|vertical layout]]<br />
[[Image:Ffshell-neo-h.png|thumb|center|200px|vertical layout]]</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/FFShellUser:Pike/FFShell2009-09-16T00:10:26Z<p>Pike: </p>
<hr />
<div>=Playing with FatFingerShell=<br />
<br />
http://www.youtube.com/watch?v=DV4p414_VJM<br />
<br />
http://fz.hobby-site.org/om/fatfingershell/<br />
<br />
[[Image:Om-template-ffv.png|thumb|left|200px|vertical layout]]<br />
[[Image:Ffshell-neo-h.png|thumb|left|200px|vertical layout]]</div>Pikehttp://wiki.openmoko.org/wiki/File:Ffshell-neo-h.pngFile:Ffshell-neo-h.png2009-09-16T00:09:49Z<p>Pike: uploaded a new version of "Image:Ffshell-neo-h.png": horizontal sketch of fatfingershell layout</p>
<hr />
<div>horizonatl fatfingershell layout (sketch)</div>Pikehttp://wiki.openmoko.org/wiki/File:Ffshell-neo-h.pngFile:Ffshell-neo-h.png2009-09-16T00:09:01Z<p>Pike: horizonatl fatfingershell layout (sketch)</p>
<hr />
<div>horizonatl fatfingershell layout (sketch)</div>Pikehttp://wiki.openmoko.org/wiki/File:Om-template-ffv.pngFile:Om-template-ffv.png2009-09-16T00:05:49Z<p>Pike: vertical sketch for fatfingershell keyboard</p>
<hr />
<div>vertical sketch for fatfingershell keyboard</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/FFShellUser:Pike/FFShell2009-09-16T00:04:30Z<p>Pike: New page: =Playing with FatFingerShell= http://www.youtube.com/watch?v=DV4p414_VJM http://fz.hobby-site.org/om/fatfingershell/</p>
<hr />
<div>=Playing with FatFingerShell=<br />
<br />
http://www.youtube.com/watch?v=DV4p414_VJM<br />
<br />
http://fz.hobby-site.org/om/fatfingershell/</div>Pikehttp://wiki.openmoko.org/wiki/User:PikeUser:Pike2009-09-16T00:03:31Z<p>Pike: </p>
<hr />
<div>I just happen to have an openmoko as my main and only phone. So whatever's worth sharing to improve it, I'll add here.<br />
<br />
* [[/OM2009 first run]] use case dd 2009/05/16<br />
* [[/Boring at best]] working on a basic paroli cleanup .. for fun<br />
* [[/Navit]] my Navit customisations<br />
* [[/Shell tools]] some shell tools I keep around<br />
* [[/Open wifi]] my open wifi setup (at home)<br />
* [[/FFShell]] playing with FatFingerShell</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/Open_wifiUser:Pike/Open wifi2009-08-27T22:16:20Z<p>Pike: /* Open Wifi */</p>
<hr />
<div>=Open Wifi=<br />
<br />
This is just my own setup. Since it works for me, at home, I copy it over everytime I flash the phone. Oh, I do try the widgets that come out of the box. But they usually dont work. <br />
<br />
Tweek as needed. YMMV.<br />
<br />
==/etc/default/dropbear==<br />
<pre><br />
DROPBEAR_PORT=*:22<br />
</pre><br />
<br />
==/etc/network/interfaces==<br />
<pre><br />
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)<br />
<br />
# The loopback interface<br />
auto lo<br />
iface lo inet loopback<br />
<br />
# Wireless interfaces<br />
iface wlan0 inet dhcp<br />
wireless_mode managed<br />
wireless_essid any<br />
iface atml0 inet dhcp<br />
<br />
# Wired or wireless interfaces<br />
iface eth0 inet dhcp<br />
# up route add default gw 192.168.1.1 <br />
up echo nameserver 192.168.1.1 > /etc/resolv.conf<br />
<br />
iface eth1 inet dhcp<br />
<br />
# Ethernet/RNDIS gadget (g_ether)<br />
# ... or on host side, usbnet and random hwaddr<br />
auto usb0<br />
iface usb0 inet static<br />
address 192.168.0.202<br />
netmask 255.255.255.0<br />
network 192.168.0.0<br />
# pike - never inet out thru usb<br />
# up route add default gw 192.168.0.200 metric 8<br />
# up echo nameserver 208.67.222.222 > /etc/resolv.conf<br />
# up echo nameserver 208.67.220.220 >> /etc/resolv.conf<br />
# down route del default gw 192.168.0.200 metric 8<br />
<br />
# Bluetooth networking<br />
iface bnep0 inet dhcp<br />
<br />
</pre></div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/Open_wifiUser:Pike/Open wifi2009-08-27T22:15:33Z<p>Pike: New page: =Open Wifi= This is just my own setup. Since it works, I copy it over everytime I flash the phone. Oh, I do try the widgets that come out of the box. But they usually dont work. ==/etc/d...</p>
<hr />
<div>=Open Wifi=<br />
<br />
This is just my own setup. Since it works, I copy it over everytime I flash the phone. Oh, I do try the widgets that come out of the box. But they usually dont work.<br />
<br />
==/etc/default/dropbear==<br />
<pre><br />
DROPBEAR_PORT=*:22<br />
</pre><br />
<br />
==/etc/network/interfaces==<br />
<pre><br />
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)<br />
<br />
# The loopback interface<br />
auto lo<br />
iface lo inet loopback<br />
<br />
# Wireless interfaces<br />
iface wlan0 inet dhcp<br />
wireless_mode managed<br />
wireless_essid any<br />
iface atml0 inet dhcp<br />
<br />
# Wired or wireless interfaces<br />
iface eth0 inet dhcp<br />
# up route add default gw 192.168.1.1 <br />
up echo nameserver 192.168.1.1 > /etc/resolv.conf<br />
<br />
iface eth1 inet dhcp<br />
<br />
# Ethernet/RNDIS gadget (g_ether)<br />
# ... or on host side, usbnet and random hwaddr<br />
auto usb0<br />
iface usb0 inet static<br />
address 192.168.0.202<br />
netmask 255.255.255.0<br />
network 192.168.0.0<br />
# pike - never inet out thru usb<br />
# up route add default gw 192.168.0.200 metric 8<br />
# up echo nameserver 208.67.222.222 > /etc/resolv.conf<br />
# up echo nameserver 208.67.220.220 >> /etc/resolv.conf<br />
# down route del default gw 192.168.0.200 metric 8<br />
<br />
# Bluetooth networking<br />
iface bnep0 inet dhcp<br />
<br />
</pre></div>Pikehttp://wiki.openmoko.org/wiki/User:PikeUser:Pike2009-08-27T22:12:51Z<p>Pike: </p>
<hr />
<div>I just happen to have an openmoko as my main and only phone. So whatever's worth sharing to improve it, I'll add here.<br />
<br />
* [[/OM2009 first run]] use case dd 2009/05/16<br />
* [[/Boring at best]] working on a basic paroli cleanup .. for fun<br />
* [[/Navit]] my Navit customisations<br />
* [[/Shell tools]] some shell tools I keep around<br />
* [[/Open wifi]] my open wifi setup (at home)</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/Shell_toolsUser:Pike/Shell tools2009-08-27T14:06:13Z<p>Pike: /* Shell Tools */</p>
<hr />
<div>=Shell Tools=<br />
<br />
So many GUIs to do so many things - and they all crash or do the wrong thing - and what i need is always sooooo simple. So lately I keep a bunch of shell scripts to do the job - and link those from /usr/share/applications, using<br />
<pre><br />
Exec=vala-terminal -e "/root/bin/somescript.sh; exit"<br />
</pre><br />
<br />
No big magic here. YMMV. Tweek as needed.<br />
<br />
==keeping the phone from falling asleep==<br />
<br />
Very usefull when using wifi or a navigator, or a alarm :-D<br />
<br />
===sleep-off.sh===<br />
<br />
<pre><br />
#!/bin/sh<br />
echo "never sleeping again"<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \<br />
org.freesmartphone.Usage.SetResourcePolicy \<br />
Display enabled <br />
sleep 5<br />
</pre><br />
<br />
===sleep-on.sh===<br />
<pre><br />
#!/bin/sh<br />
echo "Sleeping when I want"<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \<br />
org.freesmartphone.Usage.SetResourcePolicy \<br />
Display auto <br />
sleep 5<br />
</pre><br />
<br />
==wifi management==<br />
<br />
===wifi-home.sh===<br />
This ofcourse requires you have configure your network/interfaces ..<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
# power up wifi<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \<br />
org.freesmartphone.Usage.SetResourcePolicy \<br />
WiFi enabled<br />
<br />
# bounce eth0<br />
iwconfig eth0 essid your_essid_here<br />
ifdown eth0; ifup eth0<br />
<br />
sleep 30<br />
</pre><br />
<br />
===wifi-off.sh===<br />
<pre><br />
#!/bin/sh<br />
<br />
# power down wifi<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \<br />
org.freesmartphone.Usage.SetResourcePolicy \<br />
WiFi disabled<br />
<br />
sleep 5<br />
</pre><br />
<br />
==gprs management==<br />
<br />
===gprs-on.sh===<br />
<pre><br />
#!/bin/sh<br />
echo enabling gprs ..<br />
APN="internet"<br />
USERNAME=" "<br />
PASSWORD=" "<br />
BUSNAME="org.freesmartphone.ogsmd"<br />
OBJECTPATH="/org/freesmartphone/GSM/Device"<br />
METHODNAME="org.freesmartphone.GSM.PDP.ActivateContext"<br />
mdbus -s $BUSNAME $OBJECTPATH $METHODNAME $APN "$USERNAME" "$PASSWORD"<br />
sleep 5<br />
</pre><br />
<br />
===gprs-off.sh===<br />
<pre><br />
#!/bin/sh<br />
echo "Disabling gprs"<br />
BUSNAME="org.freesmartphone.ogsmd"<br />
OBJECTPATH="/org/freesmartphone/GSM/Device"<br />
METHODNAME="org.freesmartphone.GSM.PDP.DeactivateContext"<br />
mdbus -s $BUSNAME $OBJECTPATH $METHODNAME<br />
sleep 5<br />
</pre><br />
<br />
==change paroli bg==<br />
Actually, I've only done this once. Saving it here for reference.<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
BLAH=/usr/share/paroli/applications/paroli-launcher2/edje/default/images/bg.png<br />
echo "put your bg in $BLAH"<br />
<br />
cd /usr/share/paroli/applications/paroli-launcher2<br />
edje_cc -id edje/default/images -id ../common-for-edje/images -fd ../common-for-edje/fonts \<br />
edje/default/paroli-launcher.edc -o paroli-launcher.edj<br />
chmod +r paroli-launcher.edj<br />
pkill paroli<br />
DISPLAY=:0 paroli &<br />
</pre></div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/Shell_toolsUser:Pike/Shell tools2009-08-27T14:05:08Z<p>Pike: /* change paroli bg */</p>
<hr />
<div>=Shell Tools=<br />
<br />
So many GUIs to do so many things - and they all crash or do the wrong thing - and what i need is always so simple.<br />
<br />
So lately I keep a bunch of shell scripts to do the job - and link those from /usr/share/applications, as in<br />
<pre><br />
Exec=vala-terminal -e "/root/bin/somescript.sh; exit"<br />
</pre><br />
<br />
No big magic here. YMMV. <br />
<br />
==keeping the phone from falling asleep==<br />
<br />
Very usefull when using wifi or a navigator, or a alarm :-D<br />
<br />
===sleep-off.sh===<br />
<br />
<pre><br />
#!/bin/sh<br />
echo "never sleeping again"<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \<br />
org.freesmartphone.Usage.SetResourcePolicy \<br />
Display enabled <br />
sleep 5<br />
</pre><br />
<br />
===sleep-on.sh===<br />
<pre><br />
#!/bin/sh<br />
echo "Sleeping when I want"<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \<br />
org.freesmartphone.Usage.SetResourcePolicy \<br />
Display auto <br />
sleep 5<br />
</pre><br />
<br />
==wifi management==<br />
<br />
===wifi-home.sh===<br />
This ofcourse requires you have configure your network/interfaces ..<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
# power up wifi<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \<br />
org.freesmartphone.Usage.SetResourcePolicy \<br />
WiFi enabled<br />
<br />
# bounce eth0<br />
iwconfig eth0 essid your_essid_here<br />
ifdown eth0; ifup eth0<br />
<br />
sleep 30<br />
</pre><br />
<br />
===wifi-off.sh===<br />
<pre><br />
#!/bin/sh<br />
<br />
# power down wifi<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \<br />
org.freesmartphone.Usage.SetResourcePolicy \<br />
WiFi disabled<br />
<br />
sleep 5<br />
</pre><br />
<br />
==gprs management==<br />
<br />
===gprs-on.sh===<br />
<pre><br />
#!/bin/sh<br />
echo enabling gprs ..<br />
APN="internet"<br />
USERNAME=" "<br />
PASSWORD=" "<br />
BUSNAME="org.freesmartphone.ogsmd"<br />
OBJECTPATH="/org/freesmartphone/GSM/Device"<br />
METHODNAME="org.freesmartphone.GSM.PDP.ActivateContext"<br />
mdbus -s $BUSNAME $OBJECTPATH $METHODNAME $APN "$USERNAME" "$PASSWORD"<br />
sleep 5<br />
</pre><br />
<br />
===gprs-off.sh===<br />
<pre><br />
#!/bin/sh<br />
echo "Disabling gprs"<br />
BUSNAME="org.freesmartphone.ogsmd"<br />
OBJECTPATH="/org/freesmartphone/GSM/Device"<br />
METHODNAME="org.freesmartphone.GSM.PDP.DeactivateContext"<br />
mdbus -s $BUSNAME $OBJECTPATH $METHODNAME<br />
sleep 5<br />
</pre><br />
<br />
==change paroli bg==<br />
Actually, I've only done this once. Saving it here for reference.<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
BLAH=/usr/share/paroli/applications/paroli-launcher2/edje/default/images/bg.png<br />
echo "put your bg in $BLAH"<br />
<br />
cd /usr/share/paroli/applications/paroli-launcher2<br />
edje_cc -id edje/default/images -id ../common-for-edje/images -fd ../common-for-edje/fonts \<br />
edje/default/paroli-launcher.edc -o paroli-launcher.edj<br />
chmod +r paroli-launcher.edj<br />
pkill paroli<br />
DISPLAY=:0 paroli &<br />
</pre></div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/Shell_toolsUser:Pike/Shell tools2009-08-27T14:04:19Z<p>Pike: /* wifi-off.sh */</p>
<hr />
<div>=Shell Tools=<br />
<br />
So many GUIs to do so many things - and they all crash or do the wrong thing - and what i need is always so simple.<br />
<br />
So lately I keep a bunch of shell scripts to do the job - and link those from /usr/share/applications, as in<br />
<pre><br />
Exec=vala-terminal -e "/root/bin/somescript.sh; exit"<br />
</pre><br />
<br />
No big magic here. YMMV. <br />
<br />
==keeping the phone from falling asleep==<br />
<br />
Very usefull when using wifi or a navigator, or a alarm :-D<br />
<br />
===sleep-off.sh===<br />
<br />
<pre><br />
#!/bin/sh<br />
echo "never sleeping again"<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \<br />
org.freesmartphone.Usage.SetResourcePolicy \<br />
Display enabled <br />
sleep 5<br />
</pre><br />
<br />
===sleep-on.sh===<br />
<pre><br />
#!/bin/sh<br />
echo "Sleeping when I want"<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \<br />
org.freesmartphone.Usage.SetResourcePolicy \<br />
Display auto <br />
sleep 5<br />
</pre><br />
<br />
==wifi management==<br />
<br />
===wifi-home.sh===<br />
This ofcourse requires you have configure your network/interfaces ..<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
# power up wifi<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \<br />
org.freesmartphone.Usage.SetResourcePolicy \<br />
WiFi enabled<br />
<br />
# bounce eth0<br />
iwconfig eth0 essid your_essid_here<br />
ifdown eth0; ifup eth0<br />
<br />
sleep 30<br />
</pre><br />
<br />
===wifi-off.sh===<br />
<pre><br />
#!/bin/sh<br />
<br />
# power down wifi<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \<br />
org.freesmartphone.Usage.SetResourcePolicy \<br />
WiFi disabled<br />
<br />
sleep 5<br />
</pre><br />
<br />
==gprs management==<br />
<br />
===gprs-on.sh===<br />
<pre><br />
#!/bin/sh<br />
echo enabling gprs ..<br />
APN="internet"<br />
USERNAME=" "<br />
PASSWORD=" "<br />
BUSNAME="org.freesmartphone.ogsmd"<br />
OBJECTPATH="/org/freesmartphone/GSM/Device"<br />
METHODNAME="org.freesmartphone.GSM.PDP.ActivateContext"<br />
mdbus -s $BUSNAME $OBJECTPATH $METHODNAME $APN "$USERNAME" "$PASSWORD"<br />
sleep 5<br />
</pre><br />
<br />
===gprs-off.sh===<br />
<pre><br />
#!/bin/sh<br />
echo "Disabling gprs"<br />
BUSNAME="org.freesmartphone.ogsmd"<br />
OBJECTPATH="/org/freesmartphone/GSM/Device"<br />
METHODNAME="org.freesmartphone.GSM.PDP.DeactivateContext"<br />
mdbus -s $BUSNAME $OBJECTPATH $METHODNAME<br />
sleep 5<br />
</pre><br />
<br />
==change paroli bg==<br />
<pre><br />
#!/bin/sh<br />
<br />
BLAH=/usr/share/paroli/applications/paroli-launcher2/edje/default/images/bg.png<br />
echo "put your bg in $BLAH"<br />
<br />
cd /usr/share/paroli/applications/paroli-launcher2<br />
edje_cc -id edje/default/images -id ../common-for-edje/images -fd ../common-for-edje/fonts \<br />
edje/default/paroli-launcher.edc -o paroli-launcher.edj<br />
chmod +r paroli-launcher.edj<br />
pkill paroli<br />
DISPLAY=:0 paroli &<br />
</pre></div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/Shell_toolsUser:Pike/Shell tools2009-08-27T14:03:18Z<p>Pike: New page: =Shell Tools= So many GUIs to do so many things - and they all crash or do the wrong thing - and what i need is always so simple. So lately I keep a bunch of shell scripts to do the job ...</p>
<hr />
<div>=Shell Tools=<br />
<br />
So many GUIs to do so many things - and they all crash or do the wrong thing - and what i need is always so simple.<br />
<br />
So lately I keep a bunch of shell scripts to do the job - and link those from /usr/share/applications, as in<br />
<pre><br />
Exec=vala-terminal -e "/root/bin/somescript.sh; exit"<br />
</pre><br />
<br />
No big magic here. YMMV. <br />
<br />
==keeping the phone from falling asleep==<br />
<br />
Very usefull when using wifi or a navigator, or a alarm :-D<br />
<br />
===sleep-off.sh===<br />
<br />
<pre><br />
#!/bin/sh<br />
echo "never sleeping again"<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \<br />
org.freesmartphone.Usage.SetResourcePolicy \<br />
Display enabled <br />
sleep 5<br />
</pre><br />
<br />
===sleep-on.sh===<br />
<pre><br />
#!/bin/sh<br />
echo "Sleeping when I want"<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \<br />
org.freesmartphone.Usage.SetResourcePolicy \<br />
Display auto <br />
sleep 5<br />
</pre><br />
<br />
==wifi management==<br />
<br />
===wifi-home.sh===<br />
This ofcourse requires you have configure your network/interfaces ..<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
# power up wifi<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \<br />
org.freesmartphone.Usage.SetResourcePolicy \<br />
WiFi enabled<br />
<br />
# bounce eth0<br />
iwconfig eth0 essid your_essid_here<br />
ifdown eth0; ifup eth0<br />
<br />
sleep 30<br />
</pre><br />
<br />
===wifi-off.sh===<br />
<pre><br />
#!/bin/sh<br />
<br />
# keep the screen alive <br />
<br />
# power down wifi<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \<br />
org.freesmartphone.Usage.SetResourcePolicy \<br />
WiFi disabled<br />
<br />
sleep 5<br />
</pre><br />
<br />
==gprs management==<br />
<br />
===gprs-on.sh===<br />
<pre><br />
#!/bin/sh<br />
echo enabling gprs ..<br />
APN="internet"<br />
USERNAME=" "<br />
PASSWORD=" "<br />
BUSNAME="org.freesmartphone.ogsmd"<br />
OBJECTPATH="/org/freesmartphone/GSM/Device"<br />
METHODNAME="org.freesmartphone.GSM.PDP.ActivateContext"<br />
mdbus -s $BUSNAME $OBJECTPATH $METHODNAME $APN "$USERNAME" "$PASSWORD"<br />
sleep 5<br />
</pre><br />
<br />
===gprs-off.sh===<br />
<pre><br />
#!/bin/sh<br />
echo "Disabling gprs"<br />
BUSNAME="org.freesmartphone.ogsmd"<br />
OBJECTPATH="/org/freesmartphone/GSM/Device"<br />
METHODNAME="org.freesmartphone.GSM.PDP.DeactivateContext"<br />
mdbus -s $BUSNAME $OBJECTPATH $METHODNAME<br />
sleep 5<br />
</pre><br />
<br />
==change paroli bg==<br />
<pre><br />
#!/bin/sh<br />
<br />
BLAH=/usr/share/paroli/applications/paroli-launcher2/edje/default/images/bg.png<br />
echo "put your bg in $BLAH"<br />
<br />
cd /usr/share/paroli/applications/paroli-launcher2<br />
edje_cc -id edje/default/images -id ../common-for-edje/images -fd ../common-for-edje/fonts \<br />
edje/default/paroli-launcher.edc -o paroli-launcher.edj<br />
chmod +r paroli-launcher.edj<br />
pkill paroli<br />
DISPLAY=:0 paroli &<br />
</pre></div>Pikehttp://wiki.openmoko.org/wiki/User:PikeUser:Pike2009-08-27T13:51:49Z<p>Pike: </p>
<hr />
<div>I just happen to have an openmoko as my main and only phone. So whatever's worth sharing to improve it, I'll add here.<br />
<br />
* [[/OM2009 first run]] use case dd 2009/05/16<br />
* [[/Boring at best]] working on a basic paroli cleanup .. for fun<br />
* [[/Navit]] my Navit customisations<br />
* [[/Shell tools]] some shell tools I keep around</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/NavitUser:Pike/Navit2009-08-26T12:06:01Z<p>Pike: /* Pikes Navit OSD customisation */</p>
<hr />
<div>=Pikes Navit OSD customisation=<br />
<br />
I dont drive a car, so I left out the "next turn in 10 kms", "estimated arrival time", and other route features. I do like he GPS coords, so these are central. The rest is obvious imho. The current streets name on the top only appears when routing (for some reason).<br />
<br />
[[Image:navit-pike-osd.png|300px]] <br />
<br />
<pre><br />
<br />
<!--<br />
my customisation for neo freerunner<br />
<br />
--><br />
<osd enabled="yes" type="text" label="${navigation.item.street_name}" <br />
x="0" y="0" w="480" h="30" <br />
align="0" background_color="#000000cc" font_size="300" /><br />
<br />
<br />
<osd enabled="yes" type="compass" background_color="#00000000" <br />
x="160" y="-125" w="160" h="80" /><br />
<br />
<osd enabled="yes" type="button" <br />
x="-96" y="-121" <br />
command="zoom_in()" src="zoom_in.xpm"/><br />
<br />
<osd enabled="yes" type="button" <br />
x="0" y="-121" <br />
command="zoom_out()" src="zoom_out.xpm"/><br />
<br />
<osd enabled="yes" type="text" label="${vehicle.position_speed}" <br />
x="0" y="-25" w="140" h="25" <br />
align="4" background_color="#000000cc" font_size="350" /><br />
<br />
<osd enabled="yes" type="text" label="${vehicle.position_coord_geo}" <br />
x="140" y="-25" w="200" h="25" <br />
align="0" background_color="#000000cc" font_size="200" /><br />
<br />
<osd enabled="yes" type="text" label="${vehicle.position_sats_used}:${vehicle.position_qual}" <br />
x="340" y="-25" w="100" h="25" <br />
align="8" background_color="#000000cc" font_size="350" /><br />
<br />
<osd enabled="yes" type="gps_status" <br />
x="440" y="-25" w="40" h="25" <br />
align="8" background_color="#000000cc" font_size="450"/><br />
<!--<br />
/my customisation for neo freerunner<br />
<br />
--><br />
<br />
</pre></div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/NavitUser:Pike/Navit2009-08-26T12:03:15Z<p>Pike: /* Pikes Navit OSD customisation */</p>
<hr />
<div>=Pikes Navit OSD customisation=<br />
<br />
I dont drive a car, so I left out the "next turn in 10 kms" and other route features. I do like he GPS coords, so these are central. The rest is obvious imho. The current streets name on the top only appears when routing (for some reason).<br />
<br />
[[Image:navit-pike-osd.png|300px]] <br />
<br />
<pre><br />
<br />
<!--<br />
my customisation for neo freerunner<br />
<br />
--><br />
<osd enabled="yes" type="text" label="${navigation.item.street_name}" <br />
x="0" y="0" w="480" h="30" <br />
align="0" background_color="#000000cc" font_size="300" /><br />
<br />
<br />
<osd enabled="yes" type="compass" background_color="#00000000" <br />
x="160" y="-125" w="160" h="80" /><br />
<br />
<osd enabled="yes" type="button" <br />
x="-96" y="-121" <br />
command="zoom_in()" src="zoom_in.xpm"/><br />
<br />
<osd enabled="yes" type="button" <br />
x="0" y="-121" <br />
command="zoom_out()" src="zoom_out.xpm"/><br />
<br />
<osd enabled="yes" type="text" label="${vehicle.position_speed}" <br />
x="0" y="-25" w="140" h="25" <br />
align="4" background_color="#000000cc" font_size="350" /><br />
<br />
<osd enabled="yes" type="text" label="${vehicle.position_coord_geo}" <br />
x="140" y="-25" w="200" h="25" <br />
align="0" background_color="#000000cc" font_size="200" /><br />
<br />
<osd enabled="yes" type="text" label="${vehicle.position_sats_used}:${vehicle.position_qual}" <br />
x="340" y="-25" w="100" h="25" <br />
align="8" background_color="#000000cc" font_size="350" /><br />
<br />
<osd enabled="yes" type="gps_status" <br />
x="440" y="-25" w="40" h="25" <br />
align="8" background_color="#000000cc" font_size="450"/><br />
<!--<br />
/my customisation for neo freerunner<br />
<br />
--><br />
<br />
</pre></div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/NavitUser:Pike/Navit2009-08-26T12:02:30Z<p>Pike: comments</p>
<hr />
<div>=Pikes Navit OSD customisation=<br />
<br />
I dont drive a car, so I left out the "next turn in 10 kms" and other route features. I do like he GPS coords, so these are central. The rest is obvious imho. The street's name on the top only appear when routing (for some reason).<br />
<br />
[[Image:navit-pike-osd.png|300px]] <br />
<br />
<pre><br />
<br />
<!--<br />
my customisation for neo freerunner<br />
<br />
--><br />
<osd enabled="yes" type="text" label="${navigation.item.street_name}" <br />
x="0" y="0" w="480" h="30" <br />
align="0" background_color="#000000cc" font_size="300" /><br />
<br />
<br />
<osd enabled="yes" type="compass" background_color="#00000000" <br />
x="160" y="-125" w="160" h="80" /><br />
<br />
<osd enabled="yes" type="button" <br />
x="-96" y="-121" <br />
command="zoom_in()" src="zoom_in.xpm"/><br />
<br />
<osd enabled="yes" type="button" <br />
x="0" y="-121" <br />
command="zoom_out()" src="zoom_out.xpm"/><br />
<br />
<osd enabled="yes" type="text" label="${vehicle.position_speed}" <br />
x="0" y="-25" w="140" h="25" <br />
align="4" background_color="#000000cc" font_size="350" /><br />
<br />
<osd enabled="yes" type="text" label="${vehicle.position_coord_geo}" <br />
x="140" y="-25" w="200" h="25" <br />
align="0" background_color="#000000cc" font_size="200" /><br />
<br />
<osd enabled="yes" type="text" label="${vehicle.position_sats_used}:${vehicle.position_qual}" <br />
x="340" y="-25" w="100" h="25" <br />
align="8" background_color="#000000cc" font_size="350" /><br />
<br />
<osd enabled="yes" type="gps_status" <br />
x="440" y="-25" w="40" h="25" <br />
align="8" background_color="#000000cc" font_size="450"/><br />
<!--<br />
/my customisation for neo freerunner<br />
<br />
--><br />
<br />
</pre></div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/NavitUser:Pike/Navit2009-08-26T11:56:41Z<p>Pike: New page: =Pikes Navit OSD customisation= 300px <pre> <!-- my customisation for neo freerunner --> <osd enabled="yes" type="text" label="${navigation.item.s...</p>
<hr />
<div>=Pikes Navit OSD customisation=<br />
<br />
[[Image:navit-pike-osd.png|300px]] <br />
<br />
<pre><br />
<br />
<!--<br />
my customisation for neo freerunner<br />
<br />
--><br />
<osd enabled="yes" type="text" label="${navigation.item.street_name}" <br />
x="0" y="0" w="480" h="30" <br />
align="0" background_color="#000000cc" font_size="300" /><br />
<br />
<br />
<osd enabled="yes" type="compass" background_color="#00000000" <br />
x="160" y="-125" w="160" h="80" /><br />
<br />
<osd enabled="yes" type="button" <br />
x="-96" y="-121" <br />
command="zoom_in()" src="zoom_in.xpm"/><br />
<br />
<osd enabled="yes" type="button" <br />
x="0" y="-121" <br />
command="zoom_out()" src="zoom_out.xpm"/><br />
<br />
<osd enabled="yes" type="text" label="${vehicle.position_speed}" <br />
x="0" y="-25" w="140" h="25" <br />
align="4" background_color="#000000cc" font_size="350" /><br />
<br />
<osd enabled="yes" type="text" label="${vehicle.position_coord_geo}" <br />
x="140" y="-25" w="200" h="25" <br />
align="0" background_color="#000000cc" font_size="200" /><br />
<br />
<osd enabled="yes" type="text" label="${vehicle.position_sats_used}:${vehicle.position_qual}" <br />
x="340" y="-25" w="100" h="25" <br />
align="8" background_color="#000000cc" font_size="350" /><br />
<br />
<osd enabled="yes" type="gps_status" <br />
x="440" y="-25" w="40" h="25" <br />
align="8" background_color="#000000cc" font_size="450"/><br />
<!--<br />
/my customisation for neo freerunner<br />
<br />
--><br />
<br />
</pre></div>Pikehttp://wiki.openmoko.org/wiki/File:Navit-pike-osd.pngFile:Navit-pike-osd.png2009-08-26T11:52:05Z<p>Pike: preview of pikes navit customisation</p>
<hr />
<div>preview of pikes navit customisation</div>Pikehttp://wiki.openmoko.org/wiki/User:PikeUser:Pike2009-08-26T11:51:03Z<p>Pike: </p>
<hr />
<div>I just happen to have an openmoko as my main and only phone. So whatever's worth sharing to improve it, I'll add here.<br />
<br />
* [[/OM2009 first run]] use case dd 2009/05/16<br />
* [[/Boring at best]] working on a basic paroli cleanup .. for fun<br />
* [[/Navit]] my Navit customisations</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/Boring_at_bestUser:Pike/Boring at best2009-07-26T01:17:58Z<p>Pike: </p>
<hr />
<div>[[Image:BAB-List-default-1.0-grid.png|thumb|grid|left|70px]]<br />
[[Image:BAB-List-default-1.0-hilites.png|thumb|sizzle]]<br />
[[Image:BAB-List-default-1.0.png|thumb|center|300px|default listview, all options]]<br />
<br />
<br />
I love the black-and-white Paroli GUI, dubbed "Boring at Best" by someone in the mailinglist. It just needs tweeking; font sizes, alignments; it needs a few more concepts outlined - and it needs a sizzle - it should come alive when you start touching it. <br />
To prove myself it could really look nice, I did these mockups. I'm not sure what to do with them .. <br />
<br />
<br />
[[Image:Bab-1.2-3screens.png|650px]]<br />
<br />
<br />
<br />
<br />
== Some explanation==<br />
<br />
Any good interface has it's "Rythm & Rhyme". On <br />
a single screen, your eye will catch the hidden grid <br />
and swerve around primary and secondary options in <br />
a split second. This works subliminally - you wouldn't <br />
even notice, but this is what makes an interface <br />
'feel good'. This is even more true for phones, small <br />
screen, use it with one eye and one finger in a busy <br />
environment .. and between screens, your memory will <br />
recognize changes in that "Rythm and Rhyme", too. Yes, <br />
a good interface is much like a poem, or a piece of <br />
music :-) <br />
<br />
.. so I was trying to find a grid, a basic layout, <br />
that fits all purposes. At the same time, this grid <br />
should be numberfriendly, as it has to be programmed <br />
in edje. You need "a few classes" of fonts, not a <br />
new font on every page. Same with colors, shades, etc. <br />
<br />
So that's basicly what this was <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0-grid.png<br />
.. but it's already outdated :-) <br />
<br />
Such a grid should include whatever options <br />
you might think of in the future - dialogs, extra <br />
buttons, etc .. so that's basicly this <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
<br />
For example, this "big blocker bar" (a modal dialog) is not <br />
actually used anywhere, but if it *would* be, it should be <br />
there (there is a modal dialog in the "dial" and <br />
when "sending" an sms, btw). Same for the "informational <br />
bar" - a thing that should hide itself once you touch the <br />
screen imho - its not used anywhere - but if it would <br />
be, it should be right there. And hey, it could say <br />
"52 messages, 4 unread", for an instance, couldnt it ? :-) <br />
<br />
== what is new ==<br />
<br />
As little as possible :-D <br />
But, as I'm sketching and using the phone, a few things <br />
are indeed new and needed imho. <br />
<br />
====avoid next,back====<br />
The "next", "back" paradigm doesnt really work for <br />
me. I want to know *what* "next" is. "back" is not <br />
always where I came from. And above that, I don't <br />
always know where I am (this happens particularly <br />
in the settings, currently). So I've changed "back" <br />
and "next" to a virtual "path" and an "action". <br />
There could be more actions, actually (eg in sms|read, <br />
you can "delete" and "reply" a message). If you <br />
click on an action, that should become part of <br />
your path in the next screen. For example, if <br />
you are in "Setting | Wifi", the main action is <br />
"Scan". In the next screen, the path should be <br />
"Settings | Wifi | Scan". Action and Paths are <br />
CamelCased. <br />
<br />
====avoid double top bars====<br />
the "panel" (the top bar) should be removed in all <br />
screens if we are in windowed mode imho, because you now <br />
get two rows of similar icons. Ergo, there can be <br />
nothing essential in Paroli's panel that's not in the <br />
Illume panel. <br />
<br />
But there is one essential thing there now: the clock, used to <br />
return to the launcher. So we'd need a extra button in the interface<br />
to "close" a paroli app (like "msgs") for when you are <br />
in windowed mode and wouldnt have paroli's topbar available.<br />
<br />
In fact, it should look like a "close" button: if you tap <br />
around Illume, you will find the "chooser" is still <br />
hanging around and not responding until you "close" <br />
the other screen. <br />
<br />
So that's what the funny circle is in the 3rd image at <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
, a 'close button'.<br />
<br />
====show if the launcher is waiting====<br />
<br />
I also think the main screen, the launcher, should <br />
indicate it's waiting for the other app to quit. It <br />
would not harm if you are in fullscreen (since you won't see <br />
it) and it would be very beneficial in windowed mode. <br />
I have a screenshot of that, here .. <br />
<br />
<br />
====primary and secondary options====<br />
<br />
The most important thing is, I think, I differentiate <br />
between "primary" and "secondary" options: <br />
<br />
The screen is divided in lines. <br />
<br />
Each line can only have one primary, big, white, option. <br />
If you click it, the background color of the whole line <br />
quickly hilites before the screen changes. <br />
<br />
Each line can have several secondary (small, grey, lowercased) <br />
options. If you click it, only the font color quickly <br />
switches before the screen changes. <br />
<br />
I think this differentation is usefull, as it gives a user <br />
an idea about the "default" action - go forward - and several <br />
sideoptions - "delete that thing, go back" - without visually <br />
cluttering the screen. <br />
<br />
[[Category:Paroli]]</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/Boring_at_bestUser:Pike/Boring at best2009-07-26T01:15:55Z<p>Pike: /* Boring At Best */</p>
<hr />
<div>[[Image:BAB-List-default-1.0-grid.png|thumb|grid|left|70px]]<br />
[[Image:BAB-List-default-1.0-hilites.png|thumb|sizzle]]<br />
[[Image:BAB-List-default-1.0.png|thumb|center|300px|default listview, all options]]<br />
<br />
<br />
I love the black-and-white Paroli GUI, dubbed "Boring at Best" by someone in the mailinglist. It just needs tweeking; font sizes, alignments; it needs a few more concepts outlined - and it needs a sizzle - it should come alive when you start touching it. <br />
To prove myself it could really look nice, I did these mockups. I'm not sure what to do with them .. <br />
<br />
<br />
[[Image:Bab-1.2-3screens.png|650px]]<br />
<br />
== Some explanation==<br />
<br />
Any good interface has it's "Rythm & Rhyme". On <br />
a single screen, your eye will catch the hidden grid <br />
and swerve around primary and secondary options in <br />
a split second. This works subliminally - you wouldn't <br />
even notice, but this is what makes an interface <br />
'feel good'. This is even more true for phones, small <br />
screen, use it with one eye and one finger in a busy <br />
environment .. and between screens, your memory will <br />
recognize changes in that "Rythm and Rhyme", too. Yes, <br />
a good interface is much like a poem, or a piece of <br />
music :-) <br />
<br />
.. so I was trying to find a grid, a basic layout, <br />
that fits all purposes. At the same time, this grid <br />
should be numberfriendly, as it has to be programmed <br />
in edje. You need "a few classes" of fonts, not a <br />
new font on every page. Same with colors, shades, etc. <br />
<br />
So that's basicly what this was <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0-grid.png<br />
.. but it's already outdated :-) <br />
<br />
Such a grid should include whatever options <br />
you might think of in the future - dialogs, extra <br />
buttons, etc .. so that's basicly this <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
<br />
For example, this "big blocker bar" (a modal dialog) is not <br />
actually used anywhere, but if it *would* be, it should be <br />
there (there is a modal dialog in the "dial" and <br />
when "sending" an sms, btw). Same for the "informational <br />
bar" - a thing that should hide itself once you touch the <br />
screen imho - its not used anywhere - but if it would <br />
be, it should be right there. And hey, it could say <br />
"52 messages, 4 unread", for an instance, couldnt it ? :-) <br />
<br />
== what is new ==<br />
<br />
As little as possible :-D <br />
But, as I'm sketching and using the phone, a few things <br />
are indeed new and needed imho. <br />
<br />
====avoid next,back====<br />
The "next", "back" paradigm doesnt really work for <br />
me. I want to know *what* "next" is. "back" is not <br />
always where I came from. And above that, I don't <br />
always know where I am (this happens particularly <br />
in the settings, currently). So I've changed "back" <br />
and "next" to a virtual "path" and an "action". <br />
There could be more actions, actually (eg in sms|read, <br />
you can "delete" and "reply" a message). If you <br />
click on an action, that should become part of <br />
your path in the next screen. For example, if <br />
you are in "Setting | Wifi", the main action is <br />
"Scan". In the next screen, the path should be <br />
"Settings | Wifi | Scan". Action and Paths are <br />
CamelCased. <br />
<br />
====avoid double top bars====<br />
the "panel" (the top bar) should be removed in all <br />
screens if we are in windowed mode imho, because you now <br />
get two rows of similar icons. Ergo, there can be <br />
nothing essential in Paroli's panel that's not in the <br />
Illume panel. <br />
<br />
But there is one essential thing there now: the clock, used to <br />
return to the launcher. So we'd need a extra button in the interface<br />
to "close" a paroli app (like "msgs") for when you are <br />
in windowed mode and wouldnt have paroli's topbar available.<br />
<br />
In fact, it should look like a "close" button: if you tap <br />
around Illume, you will find the "chooser" is still <br />
hanging around and not responding until you "close" <br />
the other screen. <br />
<br />
So that's what the funny circle is in the 3rd image at <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
, a 'close button'.<br />
<br />
====show if the launcher is waiting====<br />
<br />
I also think the main screen, the launcher, should <br />
indicate it's waiting for the other app to quit. It <br />
would not harm if you are in fullscreen (since you won't see <br />
it) and it would be very beneficial in windowed mode. <br />
I have a screenshot of that, here .. <br />
<br />
<br />
====primary and secondary options====<br />
<br />
The most important thing is, I think, I differentiate <br />
between "primary" and "secondary" options: <br />
<br />
The screen is divided in lines. <br />
<br />
Each line can only have one primary, big, white, option. <br />
If you click it, the background color of the whole line <br />
quickly hilites before the screen changes. <br />
<br />
Each line can have several secondary (small, grey, lowercased) <br />
options. If you click it, only the font color quickly <br />
switches before the screen changes. <br />
<br />
I think this differentation is usefull, as it gives a user <br />
an idea about the "default" action - go forward - and several <br />
sideoptions - "delete that thing, go back" - without visually <br />
cluttering the screen. <br />
<br />
[[Category:Paroli]]</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/Boring_at_bestUser:Pike/Boring at best2009-07-26T01:14:40Z<p>Pike: /* Boring At Best */</p>
<hr />
<div>== Boring At Best ==<br />
<br />
<br />
<br />
<br />
<br />
[[Image:BAB-List-default-1.0-grid.png|thumb|grid|left|70px]]<br />
[[Image:BAB-List-default-1.0-hilites.png|thumb|sizzle]]<br />
[[Image:BAB-List-default-1.0.png|thumb|center|300px|default listview, all options]]<br />
<br />
<br />
I love the black-and-white Paroli GUI, dubbed "Boring at Best" by someone in the mailinglist. It just needs tweeking; font sizes, alignments; it needs a few more concepts outlined - and it needs a sizzle - it should come alive when you start touching it. <br />
To prove myself it could really look nice, I did these mockups. I'm not sure what to do with them .. <br />
<br />
<br />
[[Image:Bab-1.2-3screens.png|650px]]<br />
<br />
== Some explanation==<br />
<br />
Any good interface has it's "Rythm & Rhyme". On <br />
a single screen, your eye will catch the hidden grid <br />
and swerve around primary and secondary options in <br />
a split second. This works subliminally - you wouldn't <br />
even notice, but this is what makes an interface <br />
'feel good'. This is even more true for phones, small <br />
screen, use it with one eye and one finger in a busy <br />
environment .. and between screens, your memory will <br />
recognize changes in that "Rythm and Rhyme", too. Yes, <br />
a good interface is much like a poem, or a piece of <br />
music :-) <br />
<br />
.. so I was trying to find a grid, a basic layout, <br />
that fits all purposes. At the same time, this grid <br />
should be numberfriendly, as it has to be programmed <br />
in edje. You need "a few classes" of fonts, not a <br />
new font on every page. Same with colors, shades, etc. <br />
<br />
So that's basicly what this was <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0-grid.png<br />
.. but it's already outdated :-) <br />
<br />
Such a grid should include whatever options <br />
you might think of in the future - dialogs, extra <br />
buttons, etc .. so that's basicly this <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
<br />
For example, this "big blocker bar" (a modal dialog) is not <br />
actually used anywhere, but if it *would* be, it should be <br />
there (there is a modal dialog in the "dial" and <br />
when "sending" an sms, btw). Same for the "informational <br />
bar" - a thing that should hide itself once you touch the <br />
screen imho - its not used anywhere - but if it would <br />
be, it should be right there. And hey, it could say <br />
"52 messages, 4 unread", for an instance, couldnt it ? :-) <br />
<br />
== what is new ==<br />
<br />
As little as possible :-D <br />
But, as I'm sketching and using the phone, a few things <br />
are indeed new and needed imho. <br />
<br />
====avoid next,back====<br />
The "next", "back" paradigm doesnt really work for <br />
me. I want to know *what* "next" is. "back" is not <br />
always where I came from. And above that, I don't <br />
always know where I am (this happens particularly <br />
in the settings, currently). So I've changed "back" <br />
and "next" to a virtual "path" and an "action". <br />
There could be more actions, actually (eg in sms|read, <br />
you can "delete" and "reply" a message). If you <br />
click on an action, that should become part of <br />
your path in the next screen. For example, if <br />
you are in "Setting | Wifi", the main action is <br />
"Scan". In the next screen, the path should be <br />
"Settings | Wifi | Scan". Action and Paths are <br />
CamelCased. <br />
<br />
====avoid double top bars====<br />
the "panel" (the top bar) should be removed in all <br />
screens if we are in windowed mode imho, because you now <br />
get two rows of similar icons. Ergo, there can be <br />
nothing essential in Paroli's panel that's not in the <br />
Illume panel. <br />
<br />
But there is one essential thing there now: the clock, used to <br />
return to the launcher. So we'd need a extra button in the interface<br />
to "close" a paroli app (like "msgs") for when you are <br />
in windowed mode and wouldnt have paroli's topbar available.<br />
<br />
In fact, it should look like a "close" button: if you tap <br />
around Illume, you will find the "chooser" is still <br />
hanging around and not responding until you "close" <br />
the other screen. <br />
<br />
So that's what the funny circle is in the 3rd image at <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
, a 'close button'.<br />
<br />
====show if the launcher is waiting====<br />
<br />
I also think the main screen, the launcher, should <br />
indicate it's waiting for the other app to quit. It <br />
would not harm if you are in fullscreen (since you won't see <br />
it) and it would be very beneficial in windowed mode. <br />
I have a screenshot of that, here .. <br />
<br />
<br />
====primary and secondary options====<br />
<br />
The most important thing is, I think, I differentiate <br />
between "primary" and "secondary" options: <br />
<br />
The screen is divided in lines. <br />
<br />
Each line can only have one primary, big, white, option. <br />
If you click it, the background color of the whole line <br />
quickly hilites before the screen changes. <br />
<br />
Each line can have several secondary (small, grey, lowercased) <br />
options. If you click it, only the font color quickly <br />
switches before the screen changes. <br />
<br />
I think this differentation is usefull, as it gives a user <br />
an idea about the "default" action - go forward - and several <br />
sideoptions - "delete that thing, go back" - without visually <br />
cluttering the screen. <br />
<br />
[[Category:Paroli]]</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/Boring_at_bestUser:Pike/Boring at best2009-07-26T01:09:03Z<p>Pike: /* Boring At Best */</p>
<hr />
<div>== Boring At Best ==<br />
<br />
<br />
<br />
<br />
<br />
[[Image:BAB-List-default-1.0-grid.png|thumb|grid|left|50px]]<br />
[[Image:BAB-List-default-1.0-hilites.png|thumb|sizzle]]<br />
<br />
I love the black-and-white Paroli GUI, dubbed "Boring at Best" by someone in the mailinglist. It just needs tweeking; font sizes, alignments; it needs a few more concepts outlined - and it needs a sizzle - it should come alive when you start touching it. <br />
<br />
To prove myself it could really look nice, I did these mockups. I'm not sure what to do with them .. <br />
<br />
<br />
<br />
[[Image:Bab-1.2-3screens.png|600px]]<br />
<br />
[[Image:BAB-List-default-1.0.png|thumb|default listview, all options]]<br />
<br />
== Some explanation==<br />
<br />
Any good interface has it's "Rythm & Rhyme". On <br />
a single screen, your eye will catch the hidden grid <br />
and swerve around primary and secondary options in <br />
a split second. This works subliminally - you wouldn't <br />
even notice, but this is what makes an interface <br />
'feel good'. This is even more true for phones, small <br />
screen, use it with one eye and one finger in a busy <br />
environment .. and between screens, your memory will <br />
recognize changes in that "Rythm and Rhyme", too. Yes, <br />
a good interface is much like a poem, or a piece of <br />
music :-) <br />
<br />
.. so I was trying to find a grid, a basic layout, <br />
that fits all purposes. At the same time, this grid <br />
should be numberfriendly, as it has to be programmed <br />
in edje. You need "a few classes" of fonts, not a <br />
new font on every page. Same with colors, shades, etc. <br />
<br />
So that's basicly what this was <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0-grid.png<br />
.. but it's already outdated :-) <br />
<br />
Such a grid should include whatever options <br />
you might think of in the future - dialogs, extra <br />
buttons, etc .. so that's basicly this <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
<br />
For example, this "big blocker bar" (a modal dialog) is not <br />
actually used anywhere, but if it *would* be, it should be <br />
there (there is a modal dialog in the "dial" and <br />
when "sending" an sms, btw). Same for the "informational <br />
bar" - a thing that should hide itself once you touch the <br />
screen imho - its not used anywhere - but if it would <br />
be, it should be right there. And hey, it could say <br />
"52 messages, 4 unread", for an instance, couldnt it ? :-) <br />
<br />
== what is new ==<br />
<br />
As little as possible :-D <br />
But, as I'm sketching and using the phone, a few things <br />
are indeed new and needed imho. <br />
<br />
====avoid next,back====<br />
The "next", "back" paradigm doesnt really work for <br />
me. I want to know *what* "next" is. "back" is not <br />
always where I came from. And above that, I don't <br />
always know where I am (this happens particularly <br />
in the settings, currently). So I've changed "back" <br />
and "next" to a virtual "path" and an "action". <br />
There could be more actions, actually (eg in sms|read, <br />
you can "delete" and "reply" a message). If you <br />
click on an action, that should become part of <br />
your path in the next screen. For example, if <br />
you are in "Setting | Wifi", the main action is <br />
"Scan". In the next screen, the path should be <br />
"Settings | Wifi | Scan". Action and Paths are <br />
CamelCased. <br />
<br />
====avoid double top bars====<br />
the "panel" (the top bar) should be removed in all <br />
screens if we are in windowed mode imho, because you now <br />
get two rows of similar icons. Ergo, there can be <br />
nothing essential in Paroli's panel that's not in the <br />
Illume panel. <br />
<br />
But there is one essential thing there now: the clock, used to <br />
return to the launcher. So we'd need a extra button in the interface<br />
to "close" a paroli app (like "msgs") for when you are <br />
in windowed mode and wouldnt have paroli's topbar available.<br />
<br />
In fact, it should look like a "close" button: if you tap <br />
around Illume, you will find the "chooser" is still <br />
hanging around and not responding until you "close" <br />
the other screen. <br />
<br />
So that's what the funny circle is in the 3rd image at <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
, a 'close button'.<br />
<br />
====show if the launcher is waiting====<br />
<br />
I also think the main screen, the launcher, should <br />
indicate it's waiting for the other app to quit. It <br />
would not harm if you are in fullscreen (since you won't see <br />
it) and it would be very beneficial in windowed mode. <br />
I have a screenshot of that, here .. <br />
<br />
<br />
====primary and secondary options====<br />
<br />
The most important thing is, I think, I differentiate <br />
between "primary" and "secondary" options: <br />
<br />
The screen is divided in lines. <br />
<br />
Each line can only have one primary, big, white, option. <br />
If you click it, the background color of the whole line <br />
quickly hilites before the screen changes. <br />
<br />
Each line can have several secondary (small, grey, lowercased) <br />
options. If you click it, only the font color quickly <br />
switches before the screen changes. <br />
<br />
I think this differentation is usefull, as it gives a user <br />
an idea about the "default" action - go forward - and several <br />
sideoptions - "delete that thing, go back" - without visually <br />
cluttering the screen. <br />
<br />
[[Category:Paroli]]</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/Boring_at_bestUser:Pike/Boring at best2009-07-26T01:03:42Z<p>Pike: /* Boring At Best */</p>
<hr />
<div>== Boring At Best ==<br />
<br />
<br />
<br />
<br />
<br />
[[Image:BAB-List-default-1.0-grid.png|thumb|grid|left|50px]]<br />
<br />
I love the black-and-white Paroli GUI, dubbed "Boring at Best" by someone in the mailinglist. It just needs tweeking; font sizes, alignments; it needs a few more concepts outlined - and it needs a sizzle - it should come alive when you start touching it. <br />
<br />
To prove myself it could really look nice, I did these mockups. I'm not sure what to do with them .. <br />
<br />
<br />
[[Image:BAB-List-default-1.0-hilites.png|thumb|sizzle]]<br />
[[Image:BAB-List-default-1.0.png|thumb|default listview, all options]]<br />
[[Image:Bab-1.2-3screens.png|450px]]<br />
<br />
== Some explanation==<br />
<br />
Any good interface has it's "Rythm & Rhyme". On <br />
a single screen, your eye will catch the hidden grid <br />
and swerve around primary and secondary options in <br />
a split second. This works subliminally - you wouldn't <br />
even notice, but this is what makes an interface <br />
'feel good'. This is even more true for phones, small <br />
screen, use it with one eye and one finger in a busy <br />
environment .. and between screens, your memory will <br />
recognize changes in that "Rythm and Rhyme", too. Yes, <br />
a good interface is much like a poem, or a piece of <br />
music :-) <br />
<br />
.. so I was trying to find a grid, a basic layout, <br />
that fits all purposes. At the same time, this grid <br />
should be numberfriendly, as it has to be programmed <br />
in edje. You need "a few classes" of fonts, not a <br />
new font on every page. Same with colors, shades, etc. <br />
<br />
So that's basicly what this was <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0-grid.png<br />
.. but it's already outdated :-) <br />
<br />
Such a grid should include whatever options <br />
you might think of in the future - dialogs, extra <br />
buttons, etc .. so that's basicly this <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
<br />
For example, this "big blocker bar" (a modal dialog) is not <br />
actually used anywhere, but if it *would* be, it should be <br />
there (there is a modal dialog in the "dial" and <br />
when "sending" an sms, btw). Same for the "informational <br />
bar" - a thing that should hide itself once you touch the <br />
screen imho - its not used anywhere - but if it would <br />
be, it should be right there. And hey, it could say <br />
"52 messages, 4 unread", for an instance, couldnt it ? :-) <br />
<br />
== what is new ==<br />
<br />
As little as possible :-D <br />
But, as I'm sketching and using the phone, a few things <br />
are indeed new and needed imho. <br />
<br />
====avoid next,back====<br />
The "next", "back" paradigm doesnt really work for <br />
me. I want to know *what* "next" is. "back" is not <br />
always where I came from. And above that, I don't <br />
always know where I am (this happens particularly <br />
in the settings, currently). So I've changed "back" <br />
and "next" to a virtual "path" and an "action". <br />
There could be more actions, actually (eg in sms|read, <br />
you can "delete" and "reply" a message). If you <br />
click on an action, that should become part of <br />
your path in the next screen. For example, if <br />
you are in "Setting | Wifi", the main action is <br />
"Scan". In the next screen, the path should be <br />
"Settings | Wifi | Scan". Action and Paths are <br />
CamelCased. <br />
<br />
====avoid double top bars====<br />
the "panel" (the top bar) should be removed in all <br />
screens if we are in windowed mode imho, because you now <br />
get two rows of similar icons. Ergo, there can be <br />
nothing essential in Paroli's panel that's not in the <br />
Illume panel. <br />
<br />
But there is one essential thing there now: the clock, used to <br />
return to the launcher. So we'd need a extra button in the interface<br />
to "close" a paroli app (like "msgs") for when you are <br />
in windowed mode and wouldnt have paroli's topbar available.<br />
<br />
In fact, it should look like a "close" button: if you tap <br />
around Illume, you will find the "chooser" is still <br />
hanging around and not responding until you "close" <br />
the other screen. <br />
<br />
So that's what the funny circle is in the 3rd image at <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
, a 'close button'.<br />
<br />
====show if the launcher is waiting====<br />
<br />
I also think the main screen, the launcher, should <br />
indicate it's waiting for the other app to quit. It <br />
would not harm if you are in fullscreen (since you won't see <br />
it) and it would be very beneficial in windowed mode. <br />
I have a screenshot of that, here .. <br />
<br />
<br />
====primary and secondary options====<br />
<br />
The most important thing is, I think, I differentiate <br />
between "primary" and "secondary" options: <br />
<br />
The screen is divided in lines. <br />
<br />
Each line can only have one primary, big, white, option. <br />
If you click it, the background color of the whole line <br />
quickly hilites before the screen changes. <br />
<br />
Each line can have several secondary (small, grey, lowercased) <br />
options. If you click it, only the font color quickly <br />
switches before the screen changes. <br />
<br />
I think this differentation is usefull, as it gives a user <br />
an idea about the "default" action - go forward - and several <br />
sideoptions - "delete that thing, go back" - without visually <br />
cluttering the screen. <br />
<br />
[[Category:Paroli]]</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/Boring_at_bestUser:Pike/Boring at best2009-07-26T01:02:24Z<p>Pike: /* Boring At Best */</p>
<hr />
<div>== Boring At Best ==<br />
<br />
<br />
<br />
]<br />
<br />
[[Image:BAB-List-default-1.0-grid.png|thumb|grid|left|50px]]<br />
<br />
I love the black-and-white Paroli GUI, dubbed "Boring at Best" by someone in the mailinglist. It just needs tweeking; font sizes, alignments; it needs a few more concepts outlined - and it needs a sizzle - it should come alive when you start touching it. <br />
<br />
To prove myself it could really look nice, I did these mockups. I'm not sure what to do with them .. <br />
<br />
[[Image:BAB-List-default-1.0-hilites.png|thumb|sizzle]]<br />
[[Image:BAB-List-default-1.0.png|thumb|default listview, all options]]<br />
[[Image:Bab-1.2-3screens.png|450px]]<br />
<br />
== Some explanation==<br />
<br />
Any good interface has it's "Rythm & Rhyme". On <br />
a single screen, your eye will catch the hidden grid <br />
and swerve around primary and secondary options in <br />
a split second. This works subliminally - you wouldn't <br />
even notice, but this is what makes an interface <br />
'feel good'. This is even more true for phones, small <br />
screen, use it with one eye and one finger in a busy <br />
environment .. and between screens, your memory will <br />
recognize changes in that "Rythm and Rhyme", too. Yes, <br />
a good interface is much like a poem, or a piece of <br />
music :-) <br />
<br />
.. so I was trying to find a grid, a basic layout, <br />
that fits all purposes. At the same time, this grid <br />
should be numberfriendly, as it has to be programmed <br />
in edje. You need "a few classes" of fonts, not a <br />
new font on every page. Same with colors, shades, etc. <br />
<br />
So that's basicly what this was <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0-grid.png<br />
.. but it's already outdated :-) <br />
<br />
Such a grid should include whatever options <br />
you might think of in the future - dialogs, extra <br />
buttons, etc .. so that's basicly this <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
<br />
For example, this "big blocker bar" (a modal dialog) is not <br />
actually used anywhere, but if it *would* be, it should be <br />
there (there is a modal dialog in the "dial" and <br />
when "sending" an sms, btw). Same for the "informational <br />
bar" - a thing that should hide itself once you touch the <br />
screen imho - its not used anywhere - but if it would <br />
be, it should be right there. And hey, it could say <br />
"52 messages, 4 unread", for an instance, couldnt it ? :-) <br />
<br />
== what is new ==<br />
<br />
As little as possible :-D <br />
But, as I'm sketching and using the phone, a few things <br />
are indeed new and needed imho. <br />
<br />
====avoid next,back====<br />
The "next", "back" paradigm doesnt really work for <br />
me. I want to know *what* "next" is. "back" is not <br />
always where I came from. And above that, I don't <br />
always know where I am (this happens particularly <br />
in the settings, currently). So I've changed "back" <br />
and "next" to a virtual "path" and an "action". <br />
There could be more actions, actually (eg in sms|read, <br />
you can "delete" and "reply" a message). If you <br />
click on an action, that should become part of <br />
your path in the next screen. For example, if <br />
you are in "Setting | Wifi", the main action is <br />
"Scan". In the next screen, the path should be <br />
"Settings | Wifi | Scan". Action and Paths are <br />
CamelCased. <br />
<br />
====avoid double top bars====<br />
the "panel" (the top bar) should be removed in all <br />
screens if we are in windowed mode imho, because you now <br />
get two rows of similar icons. Ergo, there can be <br />
nothing essential in Paroli's panel that's not in the <br />
Illume panel. <br />
<br />
But there is one essential thing there now: the clock, used to <br />
return to the launcher. So we'd need a extra button in the interface<br />
to "close" a paroli app (like "msgs") for when you are <br />
in windowed mode and wouldnt have paroli's topbar available.<br />
<br />
In fact, it should look like a "close" button: if you tap <br />
around Illume, you will find the "chooser" is still <br />
hanging around and not responding until you "close" <br />
the other screen. <br />
<br />
So that's what the funny circle is in the 3rd image at <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
, a 'close button'.<br />
<br />
====show if the launcher is waiting====<br />
<br />
I also think the main screen, the launcher, should <br />
indicate it's waiting for the other app to quit. It <br />
would not harm if you are in fullscreen (since you won't see <br />
it) and it would be very beneficial in windowed mode. <br />
I have a screenshot of that, here .. <br />
<br />
<br />
====primary and secondary options====<br />
<br />
The most important thing is, I think, I differentiate <br />
between "primary" and "secondary" options: <br />
<br />
The screen is divided in lines. <br />
<br />
Each line can only have one primary, big, white, option. <br />
If you click it, the background color of the whole line <br />
quickly hilites before the screen changes. <br />
<br />
Each line can have several secondary (small, grey, lowercased) <br />
options. If you click it, only the font color quickly <br />
switches before the screen changes. <br />
<br />
I think this differentation is usefull, as it gives a user <br />
an idea about the "default" action - go forward - and several <br />
sideoptions - "delete that thing, go back" - without visually <br />
cluttering the screen. <br />
<br />
[[Category:Paroli]]</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/Boring_at_bestUser:Pike/Boring at best2009-07-26T00:27:23Z<p>Pike: /* avoid double top bars */</p>
<hr />
<div>== Boring At Best ==<br />
<br />
<br />
'''Explanation''':<br />
<br />
[[Image:BAB-List-default-1.0-hilites.png|thumb|sizzle]]<br />
[[Image:BAB-List-default-1.0-grid.png|thumb|grid|left|50px]]<br />
[[Image:BAB-List-default-1.0.png|thumb|default listview, all options]]<br />
<br />
I love the black-and-white Paroli GUI, dubbed "Boring at Best" by someone in the mailinglist. It just needs tweeking; font sizes, alignments; it needs a few more concepts outlined - and it needs a sizzle - it should come alive when you start touching it. <br />
<br />
To prove myself it could really look nice, I did these mockups. I'm not sure what to do with them .. <br />
<br />
<br />
[[Image:Bab-1.2-3screens.png|500px]]<br />
<br />
== Some explanation==<br />
<br />
Any good interface has it's "Rythm & Rhyme". On <br />
a single screen, your eye will catch the hidden grid <br />
and swerve around primary and secondary options in <br />
a split second. This works subliminally - you wouldn't <br />
even notice, but this is what makes an interface <br />
'feel good'. This is even more true for phones, small <br />
screen, use it with one eye and one finger in a busy <br />
environment .. and between screens, your memory will <br />
recognize changes in that "Rythm and Rhyme", too. Yes, <br />
a good interface is much like a poem, or a piece of <br />
music :-) <br />
<br />
.. so I was trying to find a grid, a basic layout, <br />
that fits all purposes. At the same time, this grid <br />
should be numberfriendly, as it has to be programmed <br />
in edje. You need "a few classes" of fonts, not a <br />
new font on every page. Same with colors, shades, etc. <br />
<br />
So that's basicly what this was <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0-grid.png<br />
.. but it's already outdated :-) <br />
<br />
Such a grid should include whatever options <br />
you might think of in the future - dialogs, extra <br />
buttons, etc .. so that's basicly this <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
<br />
For example, this "big blocker bar" (a modal dialog) is not <br />
actually used anywhere, but if it *would* be, it should be <br />
there (there is a modal dialog in the "dial" and <br />
when "sending" an sms, btw). Same for the "informational <br />
bar" - a thing that should hide itself once you touch the <br />
screen imho - its not used anywhere - but if it would <br />
be, it should be right there. And hey, it could say <br />
"52 messages, 4 unread", for an instance, couldnt it ? :-) <br />
<br />
== what is new ==<br />
<br />
As little as possible :-D <br />
But, as I'm sketching and using the phone, a few things <br />
are indeed new and needed imho. <br />
<br />
====avoid next,back====<br />
The "next", "back" paradigm doesnt really work for <br />
me. I want to know *what* "next" is. "back" is not <br />
always where I came from. And above that, I don't <br />
always know where I am (this happens particularly <br />
in the settings, currently). So I've changed "back" <br />
and "next" to a virtual "path" and an "action". <br />
There could be more actions, actually (eg in sms|read, <br />
you can "delete" and "reply" a message). If you <br />
click on an action, that should become part of <br />
your path in the next screen. For example, if <br />
you are in "Setting | Wifi", the main action is <br />
"Scan". In the next screen, the path should be <br />
"Settings | Wifi | Scan". Action and Paths are <br />
CamelCased. <br />
<br />
====avoid double top bars====<br />
the "panel" (the top bar) should be removed in all <br />
screens if we are in windowed mode imho, because you now <br />
get two rows of similar icons. Ergo, there can be <br />
nothing essential in Paroli's panel that's not in the <br />
Illume panel. <br />
<br />
But there is one essential thing there now: the clock, used to <br />
return to the launcher. So we'd need a extra button in the interface<br />
to "close" a paroli app (like "msgs") for when you are <br />
in windowed mode and wouldnt have paroli's topbar available.<br />
<br />
In fact, it should look like a "close" button: if you tap <br />
around Illume, you will find the "chooser" is still <br />
hanging around and not responding until you "close" <br />
the other screen. <br />
<br />
So that's what the funny circle is in the 3rd image at <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
, a 'close button'.<br />
<br />
====show if the launcher is waiting====<br />
<br />
I also think the main screen, the launcher, should <br />
indicate it's waiting for the other app to quit. It <br />
would not harm if you are in fullscreen (since you won't see <br />
it) and it would be very beneficial in windowed mode. <br />
I have a screenshot of that, here .. <br />
<br />
<br />
====primary and secondary options====<br />
<br />
The most important thing is, I think, I differentiate <br />
between "primary" and "secondary" options: <br />
<br />
The screen is divided in lines. <br />
<br />
Each line can only have one primary, big, white, option. <br />
If you click it, the background color of the whole line <br />
quickly hilites before the screen changes. <br />
<br />
Each line can have several secondary (small, grey, lowercased) <br />
options. If you click it, only the font color quickly <br />
switches before the screen changes. <br />
<br />
I think this differentation is usefull, as it gives a user <br />
an idea about the "default" action - go forward - and several <br />
sideoptions - "delete that thing, go back" - without visually <br />
cluttering the screen. <br />
<br />
[[Category:Paroli]]</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/Boring_at_bestUser:Pike/Boring at best2009-07-26T00:23:41Z<p>Pike: /* Boring At Best */</p>
<hr />
<div>== Boring At Best ==<br />
<br />
<br />
'''Explanation''':<br />
<br />
[[Image:BAB-List-default-1.0-hilites.png|thumb|sizzle]]<br />
[[Image:BAB-List-default-1.0-grid.png|thumb|grid|left|50px]]<br />
[[Image:BAB-List-default-1.0.png|thumb|default listview, all options]]<br />
<br />
I love the black-and-white Paroli GUI, dubbed "Boring at Best" by someone in the mailinglist. It just needs tweeking; font sizes, alignments; it needs a few more concepts outlined - and it needs a sizzle - it should come alive when you start touching it. <br />
<br />
To prove myself it could really look nice, I did these mockups. I'm not sure what to do with them .. <br />
<br />
<br />
[[Image:Bab-1.2-3screens.png|500px]]<br />
<br />
== Some explanation==<br />
<br />
Any good interface has it's "Rythm & Rhyme". On <br />
a single screen, your eye will catch the hidden grid <br />
and swerve around primary and secondary options in <br />
a split second. This works subliminally - you wouldn't <br />
even notice, but this is what makes an interface <br />
'feel good'. This is even more true for phones, small <br />
screen, use it with one eye and one finger in a busy <br />
environment .. and between screens, your memory will <br />
recognize changes in that "Rythm and Rhyme", too. Yes, <br />
a good interface is much like a poem, or a piece of <br />
music :-) <br />
<br />
.. so I was trying to find a grid, a basic layout, <br />
that fits all purposes. At the same time, this grid <br />
should be numberfriendly, as it has to be programmed <br />
in edje. You need "a few classes" of fonts, not a <br />
new font on every page. Same with colors, shades, etc. <br />
<br />
So that's basicly what this was <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0-grid.png<br />
.. but it's already outdated :-) <br />
<br />
Such a grid should include whatever options <br />
you might think of in the future - dialogs, extra <br />
buttons, etc .. so that's basicly this <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
<br />
For example, this "big blocker bar" (a modal dialog) is not <br />
actually used anywhere, but if it *would* be, it should be <br />
there (there is a modal dialog in the "dial" and <br />
when "sending" an sms, btw). Same for the "informational <br />
bar" - a thing that should hide itself once you touch the <br />
screen imho - its not used anywhere - but if it would <br />
be, it should be right there. And hey, it could say <br />
"52 messages, 4 unread", for an instance, couldnt it ? :-) <br />
<br />
== what is new ==<br />
<br />
As little as possible :-D <br />
But, as I'm sketching and using the phone, a few things <br />
are indeed new and needed imho. <br />
<br />
====avoid next,back====<br />
The "next", "back" paradigm doesnt really work for <br />
me. I want to know *what* "next" is. "back" is not <br />
always where I came from. And above that, I don't <br />
always know where I am (this happens particularly <br />
in the settings, currently). So I've changed "back" <br />
and "next" to a virtual "path" and an "action". <br />
There could be more actions, actually (eg in sms|read, <br />
you can "delete" and "reply" a message). If you <br />
click on an action, that should become part of <br />
your path in the next screen. For example, if <br />
you are in "Setting | Wifi", the main action is <br />
"Scan". In the next screen, the path should be <br />
"Settings | Wifi | Scan". Action and Paths are <br />
CamelCased. <br />
<br />
====avoid double top bars====<br />
the "panel" (the top bar) should be removed in all <br />
screens if we are in windowed mode imho, because you now <br />
get two rows of similar icons. Ergo, there can be <br />
nothing essential in Paroli's panel that's not in the <br />
Illume panel. <br />
<br />
But there is one essential thing there now: the clock, used to <br />
return to the launcher. So we'd need a button in the interface<br />
to "close" a paroli app (like "msgs") when you are <br />
in windowed mode.<br />
<br />
In fact, it should look like a "close" button: if you tap <br />
around Illume, you will find the "chooser" is still <br />
hanging around and not responding until you "close" <br />
the other screen. <br />
<br />
So that's what the funny circle is in the 3rd image at <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
, a 'close button'. <br />
<br />
====show if the launcher is waiting====<br />
<br />
I also think the main screen, the launcher, should <br />
indicate it's waiting for the other app to quit. It <br />
would not harm if you are in fullscreen (since you won't see <br />
it) and it would be very beneficial in windowed mode. <br />
I have a screenshot of that, here .. <br />
<br />
<br />
====primary and secondary options====<br />
<br />
The most important thing is, I think, I differentiate <br />
between "primary" and "secondary" options: <br />
<br />
The screen is divided in lines. <br />
<br />
Each line can only have one primary, big, white, option. <br />
If you click it, the background color of the whole line <br />
quickly hilites before the screen changes. <br />
<br />
Each line can have several secondary (small, grey, lowercased) <br />
options. If you click it, only the font color quickly <br />
switches before the screen changes. <br />
<br />
I think this differentation is usefull, as it gives a user <br />
an idea about the "default" action - go forward - and several <br />
sideoptions - "delete that thing, go back" - without visually <br />
cluttering the screen. <br />
<br />
[[Category:Paroli]]</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/Boring_at_bestUser:Pike/Boring at best2009-07-26T00:22:12Z<p>Pike: /* what is new */</p>
<hr />
<div>== Boring At Best ==<br />
<br />
<br />
'''Explanation''':<br />
<br />
[[Image:BAB-List-default-1.0-hilites.png|thumb|sizzle]]<br />
[[Image:BAB-List-default-1.0-grid.png|thumb|grid|left|50px]]<br />
[[Image:BAB-List-default-1.0.png|thumb|default listview, all options]]<br />
<br />
I love the black-and-white Paroli GUI, dubbed "Boring at Best" by someone in the mailinglist. It just needs tweeking; font sizes, alignments; it needs a few more concepts outlined - and it needs a sizzle - it should come alive when you start touching it. <br />
<br />
To prove myself it could really look nice, I did these mockups. I'm not sure what to do with them; I have similar sketches in mind (and on paper) for the Launcher and Dialer and a settings screen; and some ''style guidelines'' too .. <br />
<br />
<br />
[[Image:Bab-1.2-3screens.png|500px]]<br />
<br />
<br />
<br />
== Some explanation==<br />
<br />
Any good interface has it's "Rythm & Rhyme". On <br />
a single screen, your eye will catch the hidden grid <br />
and swerve around primary and secondary options in <br />
a split second. This works subliminally - you wouldn't <br />
even notice, but this is what makes an interface <br />
'feel good'. This is even more true for phones, small <br />
screen, use it with one eye and one finger in a busy <br />
environment .. and between screens, your memory will <br />
recognize changes in that "Rythm and Rhyme", too. Yes, <br />
a good interface is much like a poem, or a piece of <br />
music :-) <br />
<br />
.. so I was trying to find a grid, a basic layout, <br />
that fits all purposes. At the same time, this grid <br />
should be numberfriendly, as it has to be programmed <br />
in edje. You need "a few classes" of fonts, not a <br />
new font on every page. Same with colors, shades, etc. <br />
<br />
So that's basicly what this was <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0-grid.png<br />
.. but it's already outdated :-) <br />
<br />
Such a grid should include whatever options <br />
you might think of in the future - dialogs, extra <br />
buttons, etc .. so that's basicly this <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
<br />
For example, this "big blocker bar" (a modal dialog) is not <br />
actually used anywhere, but if it *would* be, it should be <br />
there (there is a modal dialog in the "dial" and <br />
when "sending" an sms, btw). Same for the "informational <br />
bar" - a thing that should hide itself once you touch the <br />
screen imho - its not used anywhere - but if it would <br />
be, it should be right there. And hey, it could say <br />
"52 messages, 4 unread", for an instance, couldnt it ? :-) <br />
<br />
== what is new ==<br />
<br />
As little as possible :-D <br />
But, as I'm sketching and using the phone, a few things <br />
are indeed new and needed imho. <br />
<br />
====avoid next,back====<br />
The "next", "back" paradigm doesnt really work for <br />
me. I want to know *what* "next" is. "back" is not <br />
always where I came from. And above that, I don't <br />
always know where I am (this happens particularly <br />
in the settings, currently). So I've changed "back" <br />
and "next" to a virtual "path" and an "action". <br />
There could be more actions, actually (eg in sms|read, <br />
you can "delete" and "reply" a message). If you <br />
click on an action, that should become part of <br />
your path in the next screen. For example, if <br />
you are in "Setting | Wifi", the main action is <br />
"Scan". In the next screen, the path should be <br />
"Settings | Wifi | Scan". Action and Paths are <br />
CamelCased. <br />
<br />
====avoid double top bars====<br />
the "panel" (the top bar) should be removed in all <br />
screens if we are in windowed mode imho, because you now <br />
get two rows of similar icons. Ergo, there can be <br />
nothing essential in Paroli's panel that's not in the <br />
Illume panel. <br />
<br />
But there is one essential thing there now: the clock, used to <br />
return to the launcher. So we'd need a button in the interface<br />
to "close" a paroli app (like "msgs") when you are <br />
in windowed mode.<br />
<br />
In fact, it should look like a "close" button: if you tap <br />
around Illume, you will find the "chooser" is still <br />
hanging around and not responding until you "close" <br />
the other screen. <br />
<br />
So that's what the funny circle is in the 3rd image at <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
, a 'close button'. <br />
<br />
====show if the launcher is waiting====<br />
<br />
I also think the main screen, the launcher, should <br />
indicate it's waiting for the other app to quit. It <br />
would not harm if you are in fullscreen (since you won't see <br />
it) and it would be very beneficial in windowed mode. <br />
I have a screenshot of that, here .. <br />
<br />
<br />
====primary and secondary options====<br />
<br />
The most important thing is, I think, I differentiate <br />
between "primary" and "secondary" options: <br />
<br />
The screen is divided in lines. <br />
<br />
Each line can only have one primary, big, white, option. <br />
If you click it, the background color of the whole line <br />
quickly hilites before the screen changes. <br />
<br />
Each line can have several secondary (small, grey, lowercased) <br />
options. If you click it, only the font color quickly <br />
switches before the screen changes. <br />
<br />
I think this differentation is usefull, as it gives a user <br />
an idea about the "default" action - go forward - and several <br />
sideoptions - "delete that thing, go back" - without visually <br />
cluttering the screen. <br />
<br />
[[Category:Paroli]]</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/Boring_at_bestUser:Pike/Boring at best2009-07-26T00:21:38Z<p>Pike: /* primary and secondary options */</p>
<hr />
<div>== Boring At Best ==<br />
<br />
<br />
'''Explanation''':<br />
<br />
[[Image:BAB-List-default-1.0-hilites.png|thumb|sizzle]]<br />
[[Image:BAB-List-default-1.0-grid.png|thumb|grid|left|50px]]<br />
[[Image:BAB-List-default-1.0.png|thumb|default listview, all options]]<br />
<br />
I love the black-and-white Paroli GUI, dubbed "Boring at Best" by someone in the mailinglist. It just needs tweeking; font sizes, alignments; it needs a few more concepts outlined - and it needs a sizzle - it should come alive when you start touching it. <br />
<br />
To prove myself it could really look nice, I did these mockups. I'm not sure what to do with them; I have similar sketches in mind (and on paper) for the Launcher and Dialer and a settings screen; and some ''style guidelines'' too .. <br />
<br />
<br />
[[Image:Bab-1.2-3screens.png|500px]]<br />
<br />
<br />
<br />
== Some explanation==<br />
<br />
Any good interface has it's "Rythm & Rhyme". On <br />
a single screen, your eye will catch the hidden grid <br />
and swerve around primary and secondary options in <br />
a split second. This works subliminally - you wouldn't <br />
even notice, but this is what makes an interface <br />
'feel good'. This is even more true for phones, small <br />
screen, use it with one eye and one finger in a busy <br />
environment .. and between screens, your memory will <br />
recognize changes in that "Rythm and Rhyme", too. Yes, <br />
a good interface is much like a poem, or a piece of <br />
music :-) <br />
<br />
.. so I was trying to find a grid, a basic layout, <br />
that fits all purposes. At the same time, this grid <br />
should be numberfriendly, as it has to be programmed <br />
in edje. You need "a few classes" of fonts, not a <br />
new font on every page. Same with colors, shades, etc. <br />
<br />
So that's basicly what this was <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0-grid.png<br />
.. but it's already outdated :-) <br />
<br />
Such a grid should include whatever options <br />
you might think of in the future - dialogs, extra <br />
buttons, etc .. so that's basicly this <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
<br />
For example, this "big blocker bar" (a modal dialog) is not <br />
actually used anywhere, but if it *would* be, it should be <br />
there (there is a modal dialog in the "dial" and <br />
when "sending" an sms, btw). Same for the "informational <br />
bar" - a thing that should hide itself once you touch the <br />
screen imho - its not used anywhere - but if it would <br />
be, it should be right there. And hey, it could say <br />
"52 messages, 4 unread", for an instance, couldnt it ? :-) <br />
<br />
=== what is new ===<br />
<br />
As little as possible :-D <br />
But, as I'm sketching and using the phone, a few things <br />
are indeed new and needed imho. <br />
<br />
====avoid next,back====<br />
The "next", "back" paradigm doesnt really work for <br />
me. I want to know *what* "next" is. "back" is not <br />
always where I came from. And above that, I don't <br />
always know where I am (this happens particularly <br />
in the settings, currently). So I've changed "back" <br />
and "next" to a virtual "path" and an "action". <br />
There could be more actions, actually (eg in sms|read, <br />
you can "delete" and "reply" a message). If you <br />
click on an action, that should become part of <br />
your path in the next screen. For example, if <br />
you are in "Setting | Wifi", the main action is <br />
"Scan". In the next screen, the path should be <br />
"Settings | Wifi | Scan". Action and Paths are <br />
CamelCased. <br />
<br />
====avoid double top bars====<br />
the "panel" (the top bar) should be removed in all <br />
screens if we are in windowed mode imho, because you now <br />
get two rows of similar icons. Ergo, there can be <br />
nothing essential in Paroli's panel that's not in the <br />
Illume panel. <br />
<br />
But there is one essential thing there now: the clock, used to <br />
return to the launcher. So we'd need a button in the interface<br />
to "close" a paroli app (like "msgs") when you are <br />
in windowed mode.<br />
<br />
In fact, it should look like a "close" button: if you tap <br />
around Illume, you will find the "chooser" is still <br />
hanging around and not responding until you "close" <br />
the other screen. <br />
<br />
So that's what the funny circle is in the 3rd image at <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
, a 'close button'. <br />
<br />
====show if the launcher is waiting====<br />
<br />
I also think the main screen, the launcher, should <br />
indicate it's waiting for the other app to quit. It <br />
would not harm if you are in fullscreen (since you won't see <br />
it) and it would be very beneficial in windowed mode. <br />
I have a screenshot of that, here .. <br />
<br />
<br />
====primary and secondary options====<br />
<br />
The most important thing is, I think, I differentiate <br />
between "primary" and "secondary" options: <br />
<br />
The screen is divided in lines. <br />
<br />
Each line can only have one primary, big, white, option. <br />
If you click it, the background color of the whole line <br />
quickly hilites before the screen changes. <br />
<br />
Each line can have several secondary (small, grey, lowercased) <br />
options. If you click it, only the font color quickly <br />
switches before the screen changes. <br />
<br />
I think this differentation is usefull, as it gives a user <br />
an idea about the "default" action - go forward - and several <br />
sideoptions - "delete that thing, go back" - without visually <br />
cluttering the screen. <br />
<br />
[[Category:Paroli]]</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/Boring_at_bestUser:Pike/Boring at best2009-07-26T00:20:05Z<p>Pike: from the mail</p>
<hr />
<div>== Boring At Best ==<br />
<br />
<br />
'''Explanation''':<br />
<br />
[[Image:BAB-List-default-1.0-hilites.png|thumb|sizzle]]<br />
[[Image:BAB-List-default-1.0-grid.png|thumb|grid|left|50px]]<br />
[[Image:BAB-List-default-1.0.png|thumb|default listview, all options]]<br />
<br />
I love the black-and-white Paroli GUI, dubbed "Boring at Best" by someone in the mailinglist. It just needs tweeking; font sizes, alignments; it needs a few more concepts outlined - and it needs a sizzle - it should come alive when you start touching it. <br />
<br />
To prove myself it could really look nice, I did these mockups. I'm not sure what to do with them; I have similar sketches in mind (and on paper) for the Launcher and Dialer and a settings screen; and some ''style guidelines'' too .. <br />
<br />
<br />
[[Image:Bab-1.2-3screens.png|500px]]<br />
<br />
<br />
<br />
== Some explanation==<br />
<br />
Any good interface has it's "Rythm & Rhyme". On <br />
a single screen, your eye will catch the hidden grid <br />
and swerve around primary and secondary options in <br />
a split second. This works subliminally - you wouldn't <br />
even notice, but this is what makes an interface <br />
'feel good'. This is even more true for phones, small <br />
screen, use it with one eye and one finger in a busy <br />
environment .. and between screens, your memory will <br />
recognize changes in that "Rythm and Rhyme", too. Yes, <br />
a good interface is much like a poem, or a piece of <br />
music :-) <br />
<br />
.. so I was trying to find a grid, a basic layout, <br />
that fits all purposes. At the same time, this grid <br />
should be numberfriendly, as it has to be programmed <br />
in edje. You need "a few classes" of fonts, not a <br />
new font on every page. Same with colors, shades, etc. <br />
<br />
So that's basicly what this was <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0-grid.png<br />
.. but it's already outdated :-) <br />
<br />
Such a grid should include whatever options <br />
you might think of in the future - dialogs, extra <br />
buttons, etc .. so that's basicly this <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
<br />
For example, this "big blocker bar" (a modal dialog) is not <br />
actually used anywhere, but if it *would* be, it should be <br />
there (there is a modal dialog in the "dial" and <br />
when "sending" an sms, btw). Same for the "informational <br />
bar" - a thing that should hide itself once you touch the <br />
screen imho - its not used anywhere - but if it would <br />
be, it should be right there. And hey, it could say <br />
"52 messages, 4 unread", for an instance, couldnt it ? :-) <br />
<br />
=== what is new ===<br />
<br />
As little as possible :-D <br />
But, as I'm sketching and using the phone, a few things <br />
are indeed new and needed imho. <br />
<br />
====avoid next,back====<br />
The "next", "back" paradigm doesnt really work for <br />
me. I want to know *what* "next" is. "back" is not <br />
always where I came from. And above that, I don't <br />
always know where I am (this happens particularly <br />
in the settings, currently). So I've changed "back" <br />
and "next" to a virtual "path" and an "action". <br />
There could be more actions, actually (eg in sms|read, <br />
you can "delete" and "reply" a message). If you <br />
click on an action, that should become part of <br />
your path in the next screen. For example, if <br />
you are in "Setting | Wifi", the main action is <br />
"Scan". In the next screen, the path should be <br />
"Settings | Wifi | Scan". Action and Paths are <br />
CamelCased. <br />
<br />
====avoid double top bars====<br />
the "panel" (the top bar) should be removed in all <br />
screens if we are in windowed mode imho, because you now <br />
get two rows of similar icons. Ergo, there can be <br />
nothing essential in Paroli's panel that's not in the <br />
Illume panel. <br />
<br />
But there is one essential thing there now: the clock, used to <br />
return to the launcher. So we'd need a button in the interface<br />
to "close" a paroli app (like "msgs") when you are <br />
in windowed mode.<br />
<br />
In fact, it should look like a "close" button: if you tap <br />
around Illume, you will find the "chooser" is still <br />
hanging around and not responding until you "close" <br />
the other screen. <br />
<br />
So that's what the funny circle is in the 3rd image at <br />
http://wiki.openmoko.org/wiki/Image:BAB-List-default-1.0.png<br />
, a 'close button'. <br />
<br />
====show if the launcher is waiting====<br />
<br />
I also think the main screen, the launcher, should <br />
indicate it's waiting for the other app to quit. It <br />
would not harm if you are in fullscreen (since you won't see <br />
it) and it would be very beneficial in windowed mode. <br />
I have a screenshot of that, here .. <br />
<br />
<br />
====primary and secondary options====<br />
<br />
The most important thing is, I think, I differentiate <br />
between "primary" and "secondary" options: <br />
<br />
The screen is divided in lines. <br />
<br />
Each line can only have one primary, big, white, option. <br />
If you click it, the background color of the whole line <br />
quickly hilites before the screen changes. <br />
<br />
A line can have several secondary (small, grey, lowercased) <br />
options. If you click it, only the font color quickly <br />
switches before the screen changes. <br />
<br />
I think this differentation is usefull, as it gives a user <br />
an idea about the "default" action - go forward - and several <br />
sideoptions - "delete that thing, go back" - without visually <br />
cluttering the screen. <br />
<br />
[[Category:Paroli]]</div>Pikehttp://wiki.openmoko.org/wiki/Paroli-themesParoli-themes2009-06-10T11:34:54Z<p>Pike: /* Design concept 1 */</p>
<hr />
<div>This page is here to collect the ideas, design mockups and thoughts about how [[Paroli]] could look like, how could it work. The plan is to create a new template to be used instead of the default black-and-white one. <br />
<br />
For motivation, have a look at the [http://lists.openmoko.org/pipermail/community/2009-May/048133.html Community driven redesign / new theme for Paroli] thread<br />
<br />
== GUI wishlist aka. Random ideas ==<br />
* SMS writing in landscape mode: one small line for text and HUGE keyboard to be used with your fingers while walking<br />
* Bling bling - what kind of effects do we have available? Fading, sliding..? I'd like to see it smoooth.<br />
<br />
== Design concept 1 ==<br />
'''Designer''':[[User:Pike|pike]] 19:42, 6 June 2009 (UTC)<br />
<br />
'''Explanation''':<br />
<br />
[[Image:Bab-1.2-3screens.png|thumb|3 screens]]<br />
[[Image:BAB-List-default-1.0-grid.png|thumb|grid|left|50px]]<br />
[[Image:BAB-List-default-1.0.png|thumb|listview, more options]]<br />
<br />
<br />
I love the black-and-white Paroli GUI, dubbed "Boring at Best" by someone in the mailinglist. It just needs tweeking; font sizes, alignments; it needs a few more concepts outlined - and it needs a sizzle - it should come alive when you start touching it. <br />
<br />
To prove myself it could really look nice, I did these mockups. I'm not sure what to do with them; I have similar sketches in mind (and on paper) for a settings and a texteditor screen; and some ''style guidelines'' too .. <br />
<br />
<br />
<br />
[[Category:Paroli]]<br />
<br />
== Design concept 2 ==<br />
* Designer:<br />
* Screenshots/mockups:<br />
* Explanation:<br />
<br />
[[Category:Paroli]]</div>Pikehttp://wiki.openmoko.org/wiki/Paroli-themesParoli-themes2009-06-10T11:32:34Z<p>Pike: replacing BAB sizzle with 3 screens</p>
<hr />
<div>This page is here to collect the ideas, design mockups and thoughts about how [[Paroli]] could look like, how could it work. The plan is to create a new template to be used instead of the default black-and-white one. <br />
<br />
For motivation, have a look at the [http://lists.openmoko.org/pipermail/community/2009-May/048133.html Community driven redesign / new theme for Paroli] thread<br />
<br />
== GUI wishlist aka. Random ideas ==<br />
* SMS writing in landscape mode: one small line for text and HUGE keyboard to be used with your fingers while walking<br />
* Bling bling - what kind of effects do we have available? Fading, sliding..? I'd like to see it smoooth.<br />
<br />
== Design concept 1 ==<br />
'''Designer''':[[User:Pike|pike]] 19:42, 6 June 2009 (UTC)<br />
<br />
'''Explanation''':<br />
<br />
[[Image:Bab-1.2-3screens.png|thumb|3 screens]]<br />
[[Image:BAB-List-default-1.0-grid.png|thumb|grid|left|50px]]<br />
[[Image:BAB-List-default-1.0.png|thumb|listview, more options]]<br />
<br />
<br />
I love the black-and-white Paroli GUI, dubbed "Boring at Best" by someone in the mailinglist. It just needs tweeking; font sizes, alignments; it needs a few more concepts outlined - and it needs a sizzle - it should come alive when you start touching it. <br />
<br />
To prove myself it could really look nice, I did these mockups. I'm not sure what to do with them; I have similar sketches in mind (and on paper) for the Launcher and Dialer and a settings screen; and some ''style guidelines'' too .. <br />
<br />
<br />
<br />
[[Category:Paroli]]<br />
<br />
== Design concept 2 ==<br />
* Designer:<br />
* Screenshots/mockups:<br />
* Explanation:<br />
<br />
[[Category:Paroli]]</div>Pikehttp://wiki.openmoko.org/wiki/User:Pike/Boring_at_bestUser:Pike/Boring at best2009-06-09T22:00:30Z<p>Pike: New page: == Boring At Best == '''Explanation''': sizzle 50px [[Image:BAB-List-default-1.0...</p>
<hr />
<div>== Boring At Best ==<br />
<br />
<br />
'''Explanation''':<br />
<br />
[[Image:BAB-List-default-1.0-hilites.png|thumb|sizzle]]<br />
[[Image:BAB-List-default-1.0-grid.png|thumb|grid|left|50px]]<br />
[[Image:BAB-List-default-1.0.png|thumb|default listview, all options]]<br />
<br />
I love the black-and-white Paroli GUI, dubbed "Boring at Best" by someone in the mailinglist. It just needs tweeking; font sizes, alignments; it needs a few more concepts outlined - and it needs a sizzle - it should come alive when you start touching it. <br />
<br />
To prove myself it could really look nice, I did these mockups. I'm not sure what to do with them; I have similar sketches in mind (and on paper) for the Launcher and Dialer and a settings screen; and some ''style guidelines'' too .. <br />
<br />
<br />
[[Image:Bab-1.2-3screens.png|500px]]<br />
<br />
<br />
<br />
<br />
[[Category:Paroli]]</div>Pikehttp://wiki.openmoko.org/wiki/File:Bab-1.2-3screens.pngFile:Bab-1.2-3screens.png2009-06-09T21:57:59Z<p>Pike: Comparing 3 screens of "boring at best" Paroli sketches.</p>
<hr />
<div>Comparing 3 screens of "boring at best" Paroli sketches.</div>Pikehttp://wiki.openmoko.org/wiki/User:PikeUser:Pike2009-06-09T21:55:27Z<p>Pike: </p>
<hr />
<div>I just happen to have an openmoko as my main and only phone. So whatever's worth sharing to improve it, I'll add here.<br />
<br />
* [[/OM2009 first run]] use case dd 2009/05/16<br />
* [[/Boring at best]] working on a basic paroli cleanup .. for fun</div>Pikehttp://wiki.openmoko.org/wiki/User:PikeUser:Pike2009-06-06T23:44:12Z<p>Pike: </p>
<hr />
<div>I just happen to have an openmoko as my main and only phone. So whatever's worth sharing to improve it, I'll add here.<br />
<br />
* [[/OM2009 first run]] use case dd 2009/05/16<br />
* [[Paroli-themes]] working on a basic paroli cleanup .. for fun</div>Pikehttp://wiki.openmoko.org/wiki/Paroli-themesParoli-themes2009-06-06T19:43:49Z<p>Pike: /* Design concept 1 */</p>
<hr />
<div>This page is here to collect the ideas, design mockups and thoughts about how [[Paroli]] could look like, how could it work. The plan is to create a new template to be used instead of the default black-and-white one. <br />
<br />
For motivation, have a look at the [http://lists.openmoko.org/pipermail/community/2009-May/048133.html Community driven redesign / new theme for Paroli] thread<br />
<br />
== GUI wishlist aka. Random ideas ==<br />
* SMS writing in landscape mode: one small line for text and HUGE keyboard to be used with your fingers while walking<br />
* Bling bling - what kind of effects do we have available? Fading, sliding..? I'd like to see it smoooth.<br />
<br />
== Design concept 1 ==<br />
'''Designer''':[[User:Pike|pike]] 19:42, 6 June 2009 (UTC)<br />
<br />
'''Explanation''':<br />
<br />
[[Image:BAB-List-default-1.0-hilites.png|thumb|sizzle]]<br />
[[Image:BAB-List-default-1.0-grid.png|thumb|grid|left|50px]]<br />
[[Image:BAB-List-default-1.0.png|thumb|default listview, all options]]<br />
<br />
I love the black-and-white Paroli GUI, dubbed "Boring at Best" by someone in the mailinglist. It just needs tweeking; font sizes, alignments; it needs a few more concepts outlined - and it needs a sizzle - it should come alive when you start touching it. <br />
<br />
To prove myself it could really look nice, I did these mockups. I'm not sure what to do with them; I have similar sketches in mind (and on paper) for the Launcher and Dialer and a settings screen; and some ''style guidelines'' too .. <br />
<br />
[[Category:Paroli]]<br />
<br />
== Design concept 2 ==<br />
* Designer:<br />
* Screenshots/mockups:<br />
* Explanation:<br />
<br />
[[Category:Paroli]]</div>Pikehttp://wiki.openmoko.org/wiki/Paroli-themesParoli-themes2009-06-06T19:42:57Z<p>Pike: /* Design concept 1 */</p>
<hr />
<div>This page is here to collect the ideas, design mockups and thoughts about how [[Paroli]] could look like, how could it work. The plan is to create a new template to be used instead of the default black-and-white one. <br />
<br />
For motivation, have a look at the [http://lists.openmoko.org/pipermail/community/2009-May/048133.html Community driven redesign / new theme for Paroli] thread<br />
<br />
== GUI wishlist aka. Random ideas ==<br />
* SMS writing in landscape mode: one small line for text and HUGE keyboard to be used with your fingers while walking<br />
* Bling bling - what kind of effects do we have available? Fading, sliding..? I'd like to see it smoooth.<br />
<br />
== Design concept 1 ==<br />
'''Designer''':[[User:Pike|pike]] 19:42, 6 June 2009 (UTC)<br />
<br />
'''Explanation''':<br />
<br />
[[Image:BAB-List-default-1.0-hilites.png|thumb|sizzle]]<br />
[[Image:BAB-List-default-1.0-grid.png|thumb|grid|left|50px]]<br />
[[Image:BAB-List-default-1.0.png|thumb|all options]]<br />
<br />
I love the black-and-white Paroli GUI, dubbed "Boring at Best" by someone in the mailinglist. It just needs tweeking; font sizes, alignments; it needs a few more concepts outlined - and it needs a sizzle - it should come alive when you start touching it. <br />
<br />
To prove myself it could really look nice, I did these mockups. I'm not sure what to do with them; I have similar sketches in mind (and on paper) for the Launcher and Dialer and a settings screen; and some ''style guidelines'' too .. <br />
<br />
[[Category:Paroli]]<br />
<br />
== Design concept 2 ==<br />
* Designer:<br />
* Screenshots/mockups:<br />
* Explanation:<br />
<br />
[[Category:Paroli]]</div>Pikehttp://wiki.openmoko.org/wiki/Paroli-themesParoli-themes2009-06-06T19:42:15Z<p>Pike: /* Boring at Best - 1 */</p>
<hr />
<div>This page is here to collect the ideas, design mockups and thoughts about how [[Paroli]] could look like, how could it work. The plan is to create a new template to be used instead of the default black-and-white one. <br />
<br />
For motivation, have a look at the [http://lists.openmoko.org/pipermail/community/2009-May/048133.html Community driven redesign / new theme for Paroli] thread<br />
<br />
== GUI wishlist aka. Random ideas ==<br />
* SMS writing in landscape mode: one small line for text and HUGE keyboard to be used with your fingers while walking<br />
* Bling bling - what kind of effects do we have available? Fading, sliding..? I'd like to see it smoooth.<br />
<br />
== Design concept 1 ==<br />
'''Designer''':[[User:Pike|pike]] 19:42, 6 June 2009 (UTC)<br />
<br />
'''Explanation''':<br />
<br />
[[Image:BAB-List-default-1.0-hilites.png|thumb|sizzle]]<br />
[[Image:BAB-List-default-1.0-grid.png|thumb|grid|left|50px]]<br />
[[Image:BAB-List-default-1.0.png|thumb|all options]]<br />
<br />
I love the black-and-white Paroli GUI, dubbed "Boring at Best" by someone in the mailinglist. It just needs tweeking; font sizes, alignments; it needs a few more concepts outlined - and it needs a sizzle - it should come alive when you start touching it. <br />
<br />
To prove myself it could really look nice, I did these mockups. I'm not sure what to do with them; I have similar sketches in mind (and on paper) for the Launcher and Dialer and a settings screen; but it's more then just pictures - some ""style guidelines"" too .. <br />
<br />
[[Category:Paroli]]<br />
<br />
<br />
== Design concept 2 ==<br />
* Designer:<br />
* Screenshots/mockups:<br />
* Explanation:<br />
<br />
[[Category:Paroli]]</div>Pikehttp://wiki.openmoko.org/wiki/File:BAB-List-default-1.0-grid.pngFile:BAB-List-default-1.0-grid.png2009-06-06T19:13:18Z<p>Pike: 'Boring at best' - sketch of improved paroli screen, grid view</p>
<hr />
<div>'Boring at best' - sketch of improved paroli screen, grid view</div>Pike