<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Jul 18, 2008 at 9:59 AM, Alexey Feldgendler <<a href="mailto:alexey@feldgendler.ru">alexey@feldgendler.ru</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Fri, 18 Jul 2008 01:01:08 +0200, matt joyce <<a href="mailto:matt.joyce@gmail.com">matt.joyce@gmail.com</a>><br>
wrote:<br>
<div class="Ih2E3d"><br>
> If it can be reliably established that my physical location is one of<br>
> my favourite restaurants please switch my phone to vibrate, unless my<br>
> babysitter calls.<br>
> If I miss a call or I receive an SMS from from any of my work<br>
> contacts during work hours, and I don't respond, please remind me.<br>
> If it's not during work hours, do not take any calls from contacts<br>
> exclusively in my work contacts.<br>
> If my home wifi is available and my battery is not too low, don't use<br>
> GPRS for data.<br>
> If it a WEEKDAY and 06:00, turn on, play alarm, connect to WIFI and<br>
> start getting email and rss.<br>
> At 21:00 on weekdays, switch to standby.<br>
> If my battery is low and I'm at home, remind me to charge.<br>
> If I'm at home disable my auto-lock.<br>
<br>
</div>The problem with this is that one needs to think like a programmer to<br>
describe your "ideal phone" as a set of rules like these. </blockquote><div><br>Programmers are people too. :)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Not only does<br>
one have to think analytically and dissect their concept into orthogonal,<br>
machine-checkable rules, but from your examples it's also clear that for<br>
such a wide range of possibilities a whole *language* with *expressions*<br>
(at least boolean) is necessary.<br>
</blockquote><div><br>Yes, this is precisely what I want, although it need not be overly complex.<br>Thunderbird's filter system is easy enough, MokoRules would be more complex, but the process can be broken down into small steps.<br>
<a href="http://opensourcearticles.com/nidelven/website/articles/thunderbird_15/english/part_07_images/1126606659X51">http://opensourcearticles.com/nidelven/website/articles/thunderbird_15/english/part_07_images/1126606659X51</a><br>
<br>I've always thought Outlook's rules wizard was pretty good.<br><a href="http://pubs.logicalexpressions.com/pub0009/LPMArticle.asp?ID=415">http://pubs.logicalexpressions.com/pub0009/LPMArticle.asp?ID=415</a><br>
<br>I'm frequently impressed by non-technical staff at work, who write rules to make their outlook work for them.<br><br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Moreover, if one *is* a programmer, and has learned the rule expression<br>
language, there will be bugs in the rulesets, like overlooked priorities<br>
or excessively permissive conditions, and you'll spend some time debugging<br>
it, probably missing a few important calls and alarms now and then in the<br>
process. Next step would be debugging tools for rulesets, allowing to<br>
simulate times of day, different conditions and incoming events to test<br>
the rules. Next, backup and revision control for rulesets. This is where<br>
madness lies: you have to modify and debug a program in a declarative<br>
logic language when you start dating someone because it breaks all your<br>
carefully polished ruleset. </blockquote><div><br>Agreed. This is about granularity, and the examples I gave were off the cuff and may well be unworkable in RL.<br>Sanity check can be developed too, and packaged in groups to meet the needs for Novice, Competent, Pro. <br>
Freedom to make mistakes.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Sounds like a topic for XKCD. Randall, are you<br>
by any chance reading this?</blockquote><div><br>I know what you mean.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
I understand that you must be thinking, "This phone is fully programmable,<br>
so I can make it do whatever I want". True. Now, by defining sets of<br>
possible conditions and actions and letting the user make rules out of<br>
these, you're basically saying: "Here is a computer. You can program it to<br>
do whatever you want". While this might be usable for someone who is a<br>
programmer (and who's willing to be a programmer when they deal with their<br>
cell phone), it's not a killer application. It's an absence of<br>
application; it's rather an interpreter for a programming language in<br>
which a user can write themself a killer application.<br>
</blockquote><div><br>Yes, that's what I want, I'd be happy with text config files to start with.<br>Even an offline webapp to make/test the rules, is not disagreeable to me.<br>People could publish their recipes, rulesets.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
The key to making a phone do what you, I or someone else wants is rather<br>
in analyzing our requirements and figuring out what parts are constant and<br>
what are changing. Of course, all people want different things, and the<br>
same person wants different things at different times. But the number of<br>
dimensions in the space of all reasonable people's demands is still much<br>
less than that of the space of all possible rulesets. Only a small subset<br>
of all possible rules, let alone rulesets, makes any sense at all, while<br>
the vast majority is nonsensical, such as "When WiFi is available and<br>
John's phone is nearby, mute all calls", or "If I have unread SMS on<br>
Thursday, prefer GPRS". Analyzing and isolating the axes of user demands<br>
is much harder than developing a ruleset-driven engine, but at least it<br>
has a chance of becoming usable.<br>
<font color="#888888"><br>
</font></blockquote><div><br>This reminds me of a Richard Dawkins quote, speaking about the search space of DNA, "But, however many ways there may be of being alive, it is certain that
there are vastly more ways of being dead, or rather not alive."<br><br>I think what your saying is that the more variables there are, the more possibilities of non-useful, or counter productive rules there will be.<br>
If you are, then I agree, but let's not discount the users ability.<br><br>I don't want a dumbed down phone, a lowest common denominator, I can buy one of those already.<br>I say we start with lot of possibilites and see what bubbles up, see what methods can be developed to help us not make daft rules.<br>
<br>I'm not saying a rules based approach will suit everyone, but I look forward to hear from those who are intrested.<br><br>Your comments are totally aprieciated and have given me cause to think though some areas I have not considered, but it has not disuaded me one bit. :)<br>
<br><br>Regards<br><br>Matt<br><br><br><br><br><br><br></div></div></div>