[FoRK] portals vs time

Lucas Gonze lgonze at panix.com
Mon Jan 31 16:41:59 PST 2005


A GUI with the speed of a console tool.

Ability to search and sort email in a way that doesn't suck. 
Auto-filtering according to a bunch of different properties.  These 
currently exist but are slow and inaccurate.  If these actually worked 
already, there would be no need for folders.

Really good out of the box support for mailing lists.

An address book that builds itself.  Auto-completion of recipient fields 
based on analysis of who you have written to in the past and, in general, 
the likelihood that a bit of typed stuff represents any address the mailer 
has ever seen.

Access both via the web and local software.  (IMAP takes too much manual 
intervention.)

(I haven't lived on Linux GUI since the days before Evolution was 
mature, so can't say how well it meets these criteria.)

- Lucas

On Mon, 31 Jan 2005, Luis Villa wrote:

> Just out of curiosity, what are the properties of this better client?
> Luis
>
>
> On Mon, 31 Jan 2005 14:02:34 -1000 (HST), Lucas Gonze <lgonze at panix.com> wrote:
>>
>> My mail client is still Pine, even after regularly trying out
>> alternatives.  I can easily imagine a better mail client and can't
>> understand why it doesn't exist yet.
>>
>> - Lucas
>>
>>
>> On Mon, 31 Jan 2005, Stephen D. Williams wrote:
>>
>>> I absolutely agree.
>>>
>>> I am extremely reluctant to create structured bits in any structure that I
>>> don't have complete, immediate, flexible, and guaranteed permanent access to.
>>> I end up using email as my primary knowledgebase because it meets those
>>> requirements but overall that's a poor solution.  I have been reluctant with
>>> blogs for the same reason.
>>> Wikis like TWiki actually pass the test well in some ways, but aren't enough.
>>>
>>> I've been attacking the semantic-everything problem from a number of angles
>>> and hope to "go semantic" this year, both personally and professionally.
>>> (Where "attacking" includes analysis churn of acquiring and understanding
>>> exactly what everyone means and is doing and the history involved.)
>>>
>>> sdw
>>>
>>> Strata R. Chalup wrote:
>>>
>>>> The long thread of messages about Flickr and GMail and similar doesn't seem
>>>> to include my main issue with JS portal-type sites, no matter how
>>>> well-done, and that is LAG.
>>>>
>>>> Sure, it's quick.  Sure, they have zillions of servers, yada yada.  But no
>>>> one seems to take into account all the wasted time in *point and click*.
>>>>
>>>> I can do any task on the command line in a fraction of the time it takes to
>>>> nav somebody's portal site, upload stuff, etc.  All these tasks require me
>>>> to pause between steps and wait.  Some of this can be solved by plug-ins.
>>>> However the plug-ins themselves are often to applications which in
>>>> themselves are graphical point and click.
>>>>
>>>> The real kicker comes in migration of data from one of these services to
>>>> another, or from one's own computer up to the portal.  Moving things from
>>>> portal to portal requires recreating the value added by the portal in the
>>>> first place, eg the comments, or the grouping into albums, or whatever.
>>>> For most of these portals, any time I invest in adding value to my raw
>>>> content is tied to the portal and lost.  For a few portals, like
>>>> LiveJournal, I have the option to spend even more time massaging exported
>>>> data to retain the value.  I'd have been, in some cases, better off just
>>>> keeping entries as raw txt paras with minimal embedded markup and applying
>>>> style sheets or my own PHP.  Etc.
>>>>
>>>> XML is *not* a sufficiently 'portable' form, since essentially each portal
>>>> site has its own flavor of schema.  What is truly needed is a base-level
>>>> schema for peering/portal sites, so that people have mobility for data and
>>>> there is opportunity for true data exchange.  Especially exchange with the
>>>> user's computing base and the portal site!
>>>>
>>>> I haven't yet found a portal that is worth long-term adoption when the
>>>> long-term time penalty is factored into it.  The closest I've come is LJ,
>>>> posting from a local client, and I'm finding that it's too hard to reply to
>>>> comments when compared to email-- if the commenter is not a paid account,
>>>> and thus has no user at livejournal.com address, the load/click/reply/view
>>>> cycle to leave even one response takes the time of 2 - 3 email responses.
>>>>
>>>> Give me flavored rsync, or a portal that supports cfengine, rather than all
>>>> these 'elegant' interfaces, please!  Give me a pure email interface, with
>>>> no webbyness required for interaction between portal users!  Perhaps I am a
>>>> dinosaur, but perhaps I merely have perspective.  But as my friend JXH is
>>>> fond of saying, "User suffering increases in direct proportion to knowledge
>>>> of a better way."
>>>>
>>>> _SRC
>>>>
>>>
>>>
>>> --
>>> swilliams at hpti.com http://www.hpti.com Per: sdw at lig.net http://sdw.st
>>> Stephen D. Williams 703-724-0118W 703-995-0407Fax 20147-4622 AIM: sdw
>>>
>>>
>>>
>>> --
>>> No virus found in this outgoing message.
>>> Checked by AVG Anti-Virus.
>>> Version: 7.0.300 / Virus Database: 265.8.2 - Release Date: 01/28/2005
>>>
>>> _______________________________________________
>>> FoRK mailing list
>>> http://xent.com/mailman/listinfo/fork
>>>
>> _______________________________________________
>> FoRK mailing list
>> http://xent.com/mailman/listinfo/fork
>>
> _______________________________________________
> FoRK mailing list
> http://xent.com/mailman/listinfo/fork
>


More information about the FoRK mailing list