I have bitched and moaned for quite a while about Gmail providing "searching, not sorting". True also of many Google (web)apps.
Sure, Google usually has good search.
But sorting is often the easiest way to go through a pile of stuff. Sort, and then look for, e.g., many emails from the same company that you no longer have an account with.
Anyway, I have bitched and moaned about the lack of sorting in Gmail.
And today I realized ... I can just use Thunderbird via IMAP to access by Gmail account. Thunderbird has sorting. And, in a few hours, I have been able to get rid of several thousand emails.
Actually, this is not the first time I have realized this. But when I tried it in the past Thunderbird regularly hung in annoying ways. Also, IMAP folders did not map wekll to Gmail labels. It appears more reliable now. Moreover, I am no longer trying to use Thunderbird for all of my Gmail - just for this sorting and clearing a lot of stuff out. Archiving. Deleting.
Disclaimer
Saturday, December 08, 2012
Thursday, November 15, 2012
Why Wesabe Lost to Mint - Marc Hedlund's blog
Why Wesabe Lost to Mint - Marc Hedlund's blog:
'via Blog this'
Interesting article on how one startup company (Wesabe) lost to a later entrant in the same market (Mint.com).
There are so many good memes on this post - I want to grab it all, and highlight the stuff I like.
...
There's a lot to be said for not rushing to market, and learning from the mistakes the first entrants make. ...
...
...Mint focused on making the user do almost no work at all, by automatically editing and categorizing their data...
...I was focused on trying to make the usability of editing data as easy and functional as it could be; Mint was focused on making it so you never had to do that at all. Their approach completely kicked our approach's ass. (To be defensive for just a moment, their data accuracy -- how well they automatically edited -- was really low, and anyone who looked deeply into their data at Mint, especially in the beginning, was shocked at how inaccurate it was. The point, though, is hardly anyone seems to have looked.)...
...it was far easier to have a good experience on Mint, and that good experience came far more quickly. ...
... most people simply won't care enough or get enough benefit from long-term features if a shorter-term alternative is available. ...
... Focus on what really matters: making users happy with your product as quickly as you can, and helping them as much as you can after that. If you do those better than anyone else out there you'll win. I think in this case, Mint totally won at the first (making users happy quickly), and we both totally failed at the second (actually helping people). ...
'via Blog this'
Interesting article on how one startup company (Wesabe) lost to a later entrant in the same market (Mint.com).
There are so many good memes on this post - I want to grab it all, and highlight the stuff I like.
...
There's a lot to be said for not rushing to market, and learning from the mistakes the first entrants make. ...
...
...Mint focused on making the user do almost no work at all, by automatically editing and categorizing their data...
...I was focused on trying to make the usability of editing data as easy and functional as it could be; Mint was focused on making it so you never had to do that at all. Their approach completely kicked our approach's ass. (To be defensive for just a moment, their data accuracy -- how well they automatically edited -- was really low, and anyone who looked deeply into their data at Mint, especially in the beginning, was shocked at how inaccurate it was. The point, though, is hardly anyone seems to have looked.)...
...it was far easier to have a good experience on Mint, and that good experience came far more quickly. ...
... most people simply won't care enough or get enough benefit from long-term features if a shorter-term alternative is available. ...
... Focus on what really matters: making users happy with your product as quickly as you can, and helping them as much as you can after that. If you do those better than anyone else out there you'll win. I think in this case, Mint totally won at the first (making users happy quickly), and we both totally failed at the second (actually helping people). ...
Monday, November 12, 2012
English Canadian in 1837/8?
English Canadian - Wikipedia, the free encyclopedia:
'via Blog this'
I attended a house concert by a Quebecois band yesterday.
In the lead-up to one of their songs they said, wrt the revolutions of 1837 in Lower Canada (Quebec) and Upper Canada (Ontario) "At that time the only Canadians were French Canadians".
But... this abortive revolutions established an English Canadian identity, already evolving as a result of the Loyalists and the War of 1812.
The colonies were called "Upper and Lower CANADA", after all. Upper Canada was majority English and/or American.
William Lyon Mackenzie briefly established the "Republic of Canada". (Per wikipedia - they did not teach this in my schools in Quebec. :-( )
--
http://en.wikipedia.org/wiki/Canadian_units_of_the_War_of_1812
Earlier: in the War of 1812, The Frontier Light Infantry were two English speaking companies of the otherwise mainly French Canadian Voltigeurs.
Coleman's Troop were officially The Canadian Light Dragoons.
--
English Canadian identity was probably tentative in 1837, as it is tentative in many ways even in 2012.
But saying that there were no English Canadians is just the sort of myth that a nationalist movement like Quebec creates to justify itself.
'via Blog this'
I attended a house concert by a Quebecois band yesterday.
In the lead-up to one of their songs they said, wrt the revolutions of 1837 in Lower Canada (Quebec) and Upper Canada (Ontario) "At that time the only Canadians were French Canadians".
But... this abortive revolutions established an English Canadian identity, already evolving as a result of the Loyalists and the War of 1812.
The colonies were called "Upper and Lower CANADA", after all. Upper Canada was majority English and/or American.
William Lyon Mackenzie briefly established the "Republic of Canada". (Per wikipedia - they did not teach this in my schools in Quebec. :-( )
--
http://en.wikipedia.org/wiki/Canadian_units_of_the_War_of_1812
Earlier: in the War of 1812, The Frontier Light Infantry were two English speaking companies of the otherwise mainly French Canadian Voltigeurs.
Coleman's Troop were officially The Canadian Light Dragoons.
--
English Canadian identity was probably tentative in 1837, as it is tentative in many ways even in 2012.
But saying that there were no English Canadians is just the sort of myth that a nationalist movement like Quebec creates to justify itself.
Example of a Wide-Open Google Drive Document found by Google Search
Bank Link List - Google Drive:
'via Blog this'
I was just googling for links wrt a Portland area bank, and found this Google Docs page.
While I see nothing sensitive in this document, it nevertheless seems odd to see it shared with the entire world. Although perhaps that was the intention.
Of more concern is the fact that I cannot easily see who "owns" the document. Not that that means much on the web, but it means something.
'via Blog this'
I was just googling for links wrt a Portland area bank, and found this Google Docs page.
While I see nothing sensitive in this document, it nevertheless seems odd to see it shared with the entire world. Although perhaps that was the intention.
Of more concern is the fact that I cannot easily see who "owns" the document. Not that that means much on the web, but it means something.
Wednesday, October 31, 2012
Deinterleaved blogs
It has long annoyed me that I have been using blogger and google+1 recently as the easiest way to take notes.
Last night I coded up bookmarklets to make it convenient to append to several different logs, directly into my several different wikis.
Quite a few, actually: 27 different flavors of log, each with several operations - edit, append new section, append section filling with URL, etc.
Of course I generated the code. I did not hand code more than 100 bookmarklets.
Actually, I don't have room for all of these bookmarklets. So I created a web page of them, and can drag them to my browser as needed.
TBD: place that web page somewhere public.
--
Leaving the stuff in wiki makes it easier, I hope, to eventually make assets, organized references, out of the raw logs.
--
Of course this really needs to be in a database. It is stupid to have so many different logs.
Last night I coded up bookmarklets to make it convenient to append to several different logs, directly into my several different wikis.
Quite a few, actually: 27 different flavors of log, each with several operations - edit, append new section, append section filling with URL, etc.
Of course I generated the code. I did not hand code more than 100 bookmarklets.
Actually, I don't have room for all of these bookmarklets. So I created a web page of them, and can drag them to my browser as needed.
TBD: place that web page somewhere public.
--
Leaving the stuff in wiki makes it easier, I hope, to eventually make assets, organized references, out of the raw logs.
--
Of course this really needs to be in a database. It is stupid to have so many different logs.
Saturday, October 27, 2012
Bookmarks need labels, just like Email, tasks, Calendar, ...
Let's see:
* I've tried using my Gmail label system as my To do list. Labels good. Flat labels bad.
* I just had the bright idea of trying to use my Google Chrome bookmarks file as the .. labels, structures, folders ... for tasks and emails and .. whatever. Whatever has an URL. Which is a lot of stuff.
Unfortunately, the bookmarks are strict hierarchy. Not labels.
---
Cor! Everything needs labels. Everything needs hierarchical nestable folders. It should be possible to label/tag/categorize everything in the same system. There should not be separate labels for Gmail that do not do hierarchy well, task lists for Gtask that do not do hierarchy at all, and which only allow one classification; hierarchical folders for Bookmarks.
It should be possible to have ONE system.
Sure, it should be possible to see
* I've tried using my Gmail label system as my To do list. Labels good. Flat labels bad.
* I just had the bright idea of trying to use my Google Chrome bookmarks file as the .. labels, structures, folders ... for tasks and emails and .. whatever. Whatever has an URL. Which is a lot of stuff.
Unfortunately, the bookmarks are strict hierarchy. Not labels.
---
Cor! Everything needs labels. Everything needs hierarchical nestable folders. It should be possible to label/tag/categorize everything in the same system. There should not be separate labels for Gmail that do not do hierarchy well, task lists for Gtask that do not do hierarchy at all, and which only allow one classification; hierarchical folders for Bookmarks.
It should be possible to have ONE system.
Sure, it should be possible to see
- Technical
- Computers
- OS
- Linux
- Bookmarked Web Pages
- Mailing lists
- To do
but also
- Bookmarks
- Technical
- Computers
- OS
- Linux
- Mailing Lists
- Linux [Technical / Computers / OS]
It should not be necessary to duplicate the entire hierarchy, if it is mainly sparse.
Hierarchy is good. But these are tags.
---
One system.
Memex.
Hardlinks vs. Softlinks
What do we learn from the history of UNIX hardlinks vs. softlinks?
First, UNIX hardlinks did not really help much for directories, because of the implicit assumption of hierarchy. ".." is the parent directory, but what if you have multiply parents? What if things pount to each other? You can force directory hardlinks given root, but it is a great way to get screwed up. I think that on some systems it was possible to create cycles that could lead to inodes being garbage, not refrrable. Memory leaks.
LEARNINGS: be careful.
LEARNING?: it may be "nice" to have a primary hierarchy, like .. for parent. But it may also be that we just don't really have the concepts to deal properly with more general graphs.
It was (is) much easier to deal with UNIX hardlinks to files.
But... one could get messed up because rm removed a link to an object, but did not actually remove the object itself.
LEARNING: there must be a way to say "remove the object completely", not just the link. Hmm... perhaps a notation like "rm ab/b" removing a link, "rm a/b/." removing the object itself. BTW, I often think of all objects as being directories Internal structure.
Big problem with hardlinks is not being able to link across filesystems. No matter how comprehensive your database is, there will always be stuff outside your database. You will need to link to this outside stuff. But... perhaps you can provide all of the goodness of labels, paths, reflexity, etc., for this outside stuff you link to as well as the inside stuff?
Symlinks helped with many of the manageability problems of hardlinks. At the cost of making things even harder to set up. (Have you ever managed link farms? ...)
With symlinks, there must be a primary name.
When you move the primary object, symlinks go dead.
(LEARNING: permalinks, etc.)
Symlinks do not really resolve the "how do you remove the object" problem. You just have to find the non-symlinked name. With hardlinks, there isn't really a non-symlinked name.
First, UNIX hardlinks did not really help much for directories, because of the implicit assumption of hierarchy. ".." is the parent directory, but what if you have multiply parents? What if things pount to each other? You can force directory hardlinks given root, but it is a great way to get screwed up. I think that on some systems it was possible to create cycles that could lead to inodes being garbage, not refrrable. Memory leaks.
LEARNINGS: be careful.
LEARNING?: it may be "nice" to have a primary hierarchy, like .. for parent. But it may also be that we just don't really have the concepts to deal properly with more general graphs.
It was (is) much easier to deal with UNIX hardlinks to files.
But... one could get messed up because rm removed a link to an object, but did not actually remove the object itself.
LEARNING: there must be a way to say "remove the object completely", not just the link. Hmm... perhaps a notation like "rm ab/b" removing a link, "rm a/b/." removing the object itself. BTW, I often think of all objects as being directories Internal structure.
Big problem with hardlinks is not being able to link across filesystems. No matter how comprehensive your database is, there will always be stuff outside your database. You will need to link to this outside stuff. But... perhaps you can provide all of the goodness of labels, paths, reflexity, etc., for this outside stuff you link to as well as the inside stuff?
Symlinks helped with many of the manageability problems of hardlinks. At the cost of making things even harder to set up. (Have you ever managed link farms? ...)
With symlinks, there must be a primary name.
When you move the primary object, symlinks go dead.
(LEARNING: permalinks, etc.)
Symlinks do not really resolve the "how do you remove the object" problem. You just have to find the non-symlinked name. With hardlinks, there isn't really a non-symlinked name.
Subscribe to:
Posts (Atom)
