From jwales at wikia.com  Fri Aug  1 03:08:19 2008
From: jwales at wikia.com (Jimmy Wales)
Date: Thu, 31 Jul 2008 20:08:19 -0700
Subject: [search-ui] [Search-l] Widgets
In-Reply-To: <24a809760807291909kab5f7acl79723095cb1c7c0e@mail.gmail.com>
References: <a6424d870807181235v308bbc4cn2e7f74cdfe3149a@mail.gmail.com>	<4884B486.5040405@wikia.com>	<a6424d870807220900n40bb1a97t72a1cdfaf8265133@mail.gmail.com>	<488622F9.3050307@wikia.com>	<a6424d870807221128g51977a38yed02ad9026972dcd@mail.gmail.com>	<48870619.7050608@gmx.de>	<a6424d870807230641i7b4cc753o85cc1d1e698bb52f@mail.gmail.com>	<24a809760807231642h316b9cd2vcacb450e626aaf2e@mail.gmail.com>	<488A305A.6010405@wikia.com>
	<24a809760807291909kab5f7acl79723095cb1c7c0e@mail.gmail.com>
Message-ID: <48927E23.8030905@wikia.com>

I have no opposition to "searchlets" except to note that they are mostly 
going to be useless for most end users. To use a "searchlet" like "now:" 
or "twitter:" or "torrent:" users have to learn something; most will not.

So although I have no opposition, I am not very excited by them.

What I am excited by is the application framework that invites partners 
to help us improve search by submitting regular expressions that trigger 
the return of useful objects.

If I type "jimmy wales twitter"... or rather anything that matches:
(.*?) twitter

then I should get a widget that directs me to the 'searchlet'.

Did you want to search twitter for "jimmy wales"?

Where "jimmy wales" is a link to summize.com?query=%1;

or whatever it would be.

--Jimbo


adatta02 at gmail.com wrote:
> We've been playing around with "widgets" and other "injections" for the 
> last few days.
> 
> So far, we've broken down search manipulations into "searchlets" and 
> "widgets".
> 
> As Aaron put it, "searchlets" consist of searches that support searching 
> within some subset of the universal search space.  We've been defining 
> these using a "<type>:<keyword>" syntax. An example of this search is 
> http://fp029.sjc.wikia-inc.com/search/search.html#twitter:earthquake 
> which uses summize to search twitter. We also have "video", "users", and 
> "torrent" built which presents results in a similar fashion (in the 
> normal search view with KT accessible).
> 
> Other "searchlets" we were throwing around are "now:" which would query 
> the "nowsphere" (twitter, latest blog posts, ect) to try and get a sense 
> of what people are saying about something right now. The vague aspects 
> of "searchlets" seem to be presentation and how they interact with KT.
> 
> A big question is should searchlets display in a different layout than 
> regular search (ie should we be able to display videos in a table 
> instead of a flat list? 
> http://fp029.sjc.wikia-inc.com/search/search.html#video:wikia )
> 
> The KT question is basically what happens in the corner cases. For 
> example, on a resultset for twitter:earthquake if a user "stars" or 
> "spotlights" an item and then the item fall off the first page (twitter 
> searches are sorted by date). Should this item automatically promote to 
> the first page or should the KT actions be ignored?
> 
> We've also been playing around with how to impliment and display 
> "widgets" but haven't come to much of a consensus. So far, we've been 
> "defining" widgets as additional discrete pieces of information (on top 
> of the nutch/KT results).
> 
> Jeff's implimented several widgets directly in our JS that display 
> in-line with the search results. For example, 
> http://fp029.sjc.wikia-inc.com/search/search.html#traffic%2010003 
> renders traffic information as a normal search result.
> 
> We also experimented with rendering the widgets on top of the results - 
> http://fp029.sjc.wikia-inc.com/search/search.html#Newark,%20NJ
> 
> The issue then is, should widgets render in-line with the other results 
> and therefore be subject to the same KT operations (star, delete, 
> spotlight, ect) or should they render in a seperate area and be 
> unaffected by KT. Also, what would the behavior be for keywords that 
> return multiple widgets (ie weather 10003)
> 
> Ashish
> 
> On Fri, Jul 25, 2008 at 3:58 PM, Jimmy Wales <jwales at wikia.com 
> <mailto:jwales at wikia.com>> wrote:
> 
>     This is very interesting. :)
> 
>     adatta02 at gmail.com <mailto:adatta02 at gmail.com> wrote:
>      > The big concern with allowing server side code is security. From the
>      > chat, it sounds like the plan is to hand review any code that will be
>      > run on the server and reject "dangerous" code. This seems like a
>      > daunting if not down right impossible task as any reasonably
>     complicated
>      > piece of code is going to be extremely hard to certify as "safe".
>     There
>      > are various examples of sneaking nefarious code into a seemingly safe
>      > code block famously
>     http://en.wikipedia.org/wiki/Underhanded_C_Contest
> 
>     Well, this is a typical problem faced by open source projects all the
>     time.  Whom do we trust to "commit"?  I think we just need to have clear
>     terms and be careful.  Excessive paranoia is not warranted.
> 
>      >  From a developer's standpoint - the big gain of being able to run
>      > server side code is the ability to interact with the OS layer (files,
>      > sockets, databases, ect) and libraries (GD, standard libraries,
>     ect) .
>      > However, it seems like there is no way we would be able to provide
>      > access to any OS features while simultanously gaurenteeing
>     security. It
>      > also seems like providing persistent storage through this framework
>      > would require significant infastructure.
> 
>     I don't think that's such a big part of it.  I would say that for both
>     us and for developers, the major gain of running server side is
>     performance and integration.
> 
>     I suppose there are 3 possibilities:
> 
>     1. "pure" client side - javascript can compute 3*7 and return 21.  No
>     risk, all is well. EXAMPLE: calculator
> 
>     2. "pure" server side - our servers compute something complex and
>     relying on databases, etc. - one huge advantage of doing this is that it
>     makes the code all open-source
> 
>     3. third-party "RESTful" calls - no risk, but performance is an issue,
>     as is proprietary-ness EXAMPLE: weather
> 
>      > What I'd propose is to construct a framework that mirrors the Google
>      > igoogle system. Following from this, developers would be able to
>     write
>      > javascript blocks that run on some set of triggers (either regex
>     matches
>      > or simple in_string()) Next, on the search results page, the user's
>      > browser executes this javascript snippit in an iframe (to create a
>      > sandbox) and injects any new HTML into the actual search results.
> 
>     I have no opposition to this, except for the possible performance
>     issue... we can require that before we send out the javascript, it has
>     to be open source.
> 
>      > I think allowing javascript snippits would provide a good mix between
>      > ease of development, security, as well as robustness. A javascript
>      > widget would be able to do anything that a server side widget could
>      > accomplish. It would be able to fetch and process RSS feeds, make
>     cross
>      > site XHR requests, and leverage additional "enviroment" variables we
>      > choose to make available to it.
> 
>     I am nearly convinced.
> 
> 
> 
> 
>     _______________________________________________
>     Search-UI mailing list
>     Search-UI at wikia.com <mailto:Search-UI at wikia.com>
>     http://lists.wikia.com/mailman/listinfo/search-ui
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Search-UI mailing list
> Search-UI at wikia.com
> http://lists.wikia.com/mailman/listinfo/search-ui



From balinny at gmail.com  Fri Aug  1 18:36:03 2008
From: balinny at gmail.com (Balinny)
Date: Fri, 01 Aug 2008 20:36:03 +0200
Subject: [search-ui] [Search-l] Widgets
In-Reply-To: <9131eace0807292131ye888d3fv69c7475c878cdb7c@mail.gmail.com>
References: <a6424d870807181235v308bbc4cn2e7f74cdfe3149a@mail.gmail.com>	<a6424d870807220900n40bb1a97t72a1cdfaf8265133@mail.gmail.com>	<488622F9.3050307@wikia.com>	<a6424d870807221128g51977a38yed02ad9026972dcd@mail.gmail.com>	<48870619.7050608@gmx.de>	<a6424d870807230641i7b4cc753o85cc1d1e698bb52f@mail.gmail.com>	<24a809760807231642h316b9cd2vcacb450e626aaf2e@mail.gmail.com>	<488A305A.6010405@wikia.com>	<24a809760807291909kab5f7acl79723095cb1c7c0e@mail.gmail.com>	<d0fd42530807292052u38f362f8nf429bfb639c78f70@mail.gmail.com>
	<9131eace0807292131ye888d3fv69c7475c878cdb7c@mail.gmail.com>
Message-ID: <48935793.4040904@gmail.com>

Jeff wrote:
> One problem that this presents, however, is with widgets that are 
> providing time sensitive / news-type data.  For example, if the 
> weather widget is editable...
I think that the solution is making the edit interface part of the 
widget. So, a widget must have a set of apis, such as show, voted, edit...
When you ask to edit the result, a weather widget would refuse it 
(typically, it would have hidden the edit link), a wiki widget could 
send you to the edit page, and a map widget would allow you to move the 
position in the map.


Jimmy Wales wrote:
> I have no opposition to "searchlets" except to note that they are mostly 
> going to be useless for most end users. To use a "searchlet" like "now:" 
> or "twitter:" or "torrent:" users have to learn something; most will not.
>   
Add a set of option boxes below the textbox, like the ones Google have 
for the web / pages from
site / pages from country, but offering: Search in the nowsphere, 
twitter changes, videos, users, More
With more opening a popup with the full list. I'd show inlnie the last 
used by the user, the most
popular ones (eg. images and videos) and some of them at random, so they 
can learn about the new ones.

People can learn that using it just prefixes the query with the 
searchlet, or just click it each time :)


From awgibbs at awgibbs.com  Sat Aug  2 07:07:18 2008
From: awgibbs at awgibbs.com (Andrew W. Gibbs)
Date: Sat, 2 Aug 2008 03:07:18 -0400
Subject: [search-ui] sliding window for infinite scrolling
Message-ID: <20080802070718.GB30297@raptor.commandosoftware.com>

The infinite scrolling is nifty and novel from a usability standpoint.
I wonder, however, whether it might cause resource utilization
problems since the earlier items continue to accumulate as you scroll.
This may seem inconsequential from the standpoint of a desktop
machine, but consider usage on a mobile device.  Where as the
conventional paging style guarantees O(1) memory usage, the infinite
scrolling style is O(n).  To preserve the general UI mechanics but
attain O(1) memory usage, you might instead have a sliding window of
search results with things falling off the top or bottom if the user
scrolled backward or forward respectively.  The challenge, of course,
would be that you could no longer free-ride on the browser's native
GUI faculties.  As it stands, you can "cheat" when scrolling downward
because the end of the search results coincides with the bottom of the
page, but you don't have this luxury at the top of the page.  You
could theoretically deal with that with frames, but frames feel oh so
1996.

  -- AWG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.wikia.com/pipermail/search-ui/attachments/20080802/b97f572a/attachment.bin 

From newsmarkie at googlemail.com  Mon Aug  4 16:39:07 2008
From: newsmarkie at googlemail.com (Mark (Markie))
Date: Mon, 4 Aug 2008 17:39:07 +0100
Subject: [search-ui] i18n errors
In-Reply-To: <488274F3.9030002@gmx.de>
References: <a6424d870807181339t5504758cuf8e62b73c9a72776@mail.gmail.com>
	<488274F3.9030002@gmx.de>
Message-ID: <a6424d870808040939n37438c8dv17233855712864c2@mail.gmail.com>

bump, still like it....

regards

mark

On Sun, Jul 20, 2008 at 12:12 AM, Rainer Blome <rainer.blome at gmx.de> wrote:

> Mark (Markie) wrote:
> > http://c.imagehost.org/0228/untitled_4.jpg  button is borked.
> Fixed, but not ready for public consumption.
> Jer, you offered a SVN account with checkin capability.
> Does this offer still stand?
> That would allow for individual fixes independent of bigger
> transformations.
> > but i am loving the on the fly translations :-)
> The breakage makes Jeff's technique used to implement on the fly
> translation visible :-).
> In this case, it is incorrectly applied.
>
> Rainer
>
> _______________________________________________
> Search-UI mailing list
> Search-UI at wikia.com
> http://lists.wikia.com/mailman/listinfo/search-ui
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikia.com/pipermail/search-ui/attachments/20080804/765e4279/attachment.html 

From rainer.blome at gmx.de  Wed Aug  6 00:46:09 2008
From: rainer.blome at gmx.de (Rainer Blome)
Date: Wed, 06 Aug 2008 02:46:09 +0200
Subject: [search-ui] i18n errors
In-Reply-To: <a6424d870808040939n37438c8dv17233855712864c2@mail.gmail.com>
References: <a6424d870807181339t5504758cuf8e62b73c9a72776@mail.gmail.com>	<488274F3.9030002@gmx.de>
	<a6424d870808040939n37438c8dv17233855712864c2@mail.gmail.com>
Message-ID: <4898F451.70005@gmx.de>

Mark (Markie) wrote:
> bump, still like it....
> On Sun, Jul 20, 2008 at 12:12 AM, Rainer Blome <rainer.blome at gmx.de 
> <mailto:rainer.blome at gmx.de>> wrote:
>     Mark (Markie) wrote:
>      > http://c.imagehost.org/0228/untitled_4.jpg  button is borked.
>     Fixed,

Checked in a fix for this particular button.
Please let me know of any other annoyingly visible HTML.


 > but not ready for public consumption.

The current idea for the general fix is to use separate "gettext" 
functions for different usage types:

o get_text(key, args) - fetches the text (format string) in
   i18n.onfly_lang[key] and uses it and the given args to format
   the translated text.  Records untranslated texts.
   Used by updater functions and all other translation functions.

o get_span(key, args) - returns a span with a generated id whose inner
   HTML is the translated text (whatever get_text returns).
   As a side effect, registers an updater function.
   Like Jeffrey's gettext mod when called with*out* args.

o get_title(key, args, param) - returns a span with id=param.id
   whose inner HTML is the translated text (whatever get_text returns).
   As a side effect, registers an updater function.
   Like Jeffrey's gettext mod when called *with* args.
   {id:sel.name, param:'options[' + i + '].text', pre:o.count+" "}
   This might be split up further.

This still needs work, though.

Rainer


From jeremie at jabber.org  Wed Aug  6 22:02:00 2008
From: jeremie at jabber.org (Jeremie Miller)
Date: Wed, 6 Aug 2008 17:02:00 -0500
Subject: [search-ui] sliding window for infinite scrolling
In-Reply-To: <20080802070718.GB30297@raptor.commandosoftware.com>
References: <20080802070718.GB30297@raptor.commandosoftware.com>
Message-ID: <C1265E98-CF9D-409C-BB36-3B5E0274DA14@jabber.org>

I'd prefer to start breaking out the UI for different types/ 
experiences, in subversion I checked in an exp directory with a mostly  
stripped down version where it's easier to do experimenting with UI.

I even started working on an iphone-specific version ages ago, I'm  
more for seeing lots of these skins than packing everything into one  
single interface :)

On Aug 2, 2008, at 2:07 AM, Andrew W. Gibbs wrote:

> The infinite scrolling is nifty and novel from a usability standpoint.
> I wonder, however, whether it might cause resource utilization
> problems since the earlier items continue to accumulate as you scroll.
> This may seem inconsequential from the standpoint of a desktop
> machine, but consider usage on a mobile device.  Where as the
> conventional paging style guarantees O(1) memory usage, the infinite
> scrolling style is O(n).  To preserve the general UI mechanics but
> attain O(1) memory usage, you might instead have a sliding window of
> search results with things falling off the top or bottom if the user
> scrolled backward or forward respectively.  The challenge, of course,
> would be that you could no longer free-ride on the browser's native
> GUI faculties.  As it stands, you can "cheat" when scrolling downward
> because the end of the search results coincides with the bottom of the
> page, but you don't have this luxury at the top of the page.  You
> could theoretically deal with that with frames, but frames feel oh so
> 1996.
>
>  -- AWG
> _______________________________________________
> Search-UI mailing list
> Search-UI at wikia.com
> http://lists.wikia.com/mailman/listinfo/search-ui


From phil.nelson at gmail.com  Wed Aug  6 23:02:15 2008
From: phil.nelson at gmail.com (Christian Nelson)
Date: Wed, 6 Aug 2008 19:02:15 -0400
Subject: [search-ui] Allow users to select multiple languages
Message-ID: <FF8C0941-7088-4F35-B72D-C751319D3802@zerolives.org>

I saw this idea on this blog: http://bani2.blogspot.com/2008/08/wikia-evolution.html

To my knowledge, there's no good interface in any of the big search  
engines that allows users who speak more than one language to select  
those languages and have them apply to the same search. E.G. returning  
results in english AND french, not just english OR french. This is  
something that I think could help set Wikia apart, especially with the  
large support other wiki-style projects seem to get in many non-US  
countries.

- Phil Nelson
http://philnelson.name

From jeremie at jabber.org  Wed Aug  6 23:06:20 2008
From: jeremie at jabber.org (Jeremie Miller)
Date: Wed, 6 Aug 2008 18:06:20 -0500
Subject: [search-ui] Allow users to select multiple languages
In-Reply-To: <FF8C0941-7088-4F35-B72D-C751319D3802@zerolives.org>
References: <FF8C0941-7088-4F35-B72D-C751319D3802@zerolives.org>
Message-ID: <596B329F-9123-4A87-A0AA-909BC86C321E@jabber.org>

That's a pretty wicked idea, should be totally possible with the  
framework, but will take some extra JS logic to merge everything  
together... definitely on the list IMO, now I just need to fluently  
learn another language :)

Jer

On Aug 6, 2008, at 6:02 PM, Christian Nelson wrote:

> I saw this idea on this blog: http://bani2.blogspot.com/2008/08/wikia-evolution.html
>
> To my knowledge, there's no good interface in any of the big search
> engines that allows users who speak more than one language to select
> those languages and have them apply to the same search. E.G. returning
> results in english AND french, not just english OR french. This is
> something that I think could help set Wikia apart, especially with the
> large support other wiki-style projects seem to get in many non-US
> countries.
>
> - Phil Nelson
> http://philnelson.name
> _______________________________________________
> Search-UI mailing list
> Search-UI at wikia.com
> http://lists.wikia.com/mailman/listinfo/search-ui
>


From jwales at wikia.com  Wed Aug  6 23:32:50 2008
From: jwales at wikia.com (Jimmy Wales)
Date: Wed, 06 Aug 2008 19:32:50 -0400
Subject: [search-ui] [Search-l] Widgets
In-Reply-To: <48935793.4040904@gmail.com>
References: <a6424d870807181235v308bbc4cn2e7f74cdfe3149a@mail.gmail.com>	<a6424d870807220900n40bb1a97t72a1cdfaf8265133@mail.gmail.com>	<488622F9.3050307@wikia.com>	<a6424d870807221128g51977a38yed02ad9026972dcd@mail.gmail.com>	<48870619.7050608@gmx.de>	<a6424d870807230641i7b4cc753o85cc1d1e698bb52f@mail.gmail.com>	<24a809760807231642h316b9cd2vcacb450e626aaf2e@mail.gmail.com>	<488A305A.6010405@wikia.com>	<24a809760807291909kab5f7acl79723095cb1c7c0e@mail.gmail.com>	<d0fd42530807292052u38f362f8nf429bfb639c78f70@mail.gmail.com>	<9131eace0807292131ye888d3fv69c7475c878cdb7c@mail.gmail.com>
	<48935793.4040904@gmail.com>
Message-ID: <489A34A2.5080806@wikia.com>

Balinny wrote:
> Jeff wrote:
>> One problem that this presents, however, is with widgets that are 
>> providing time sensitive / news-type data.  For example, if the 
>> weather widget is editable...
> I think that the solution is making the edit interface part of the 
> widget. So, a widget must have a set of apis, such as show, voted, edit...
> When you ask to edit the result, a weather widget would refuse it 
> (typically, it would have hidden the edit link), a wiki widget could 
> send you to the edit page, and a map widget would allow you to move the 
> position in the map.

That sounds right to me.

Also, there is the possibility of editing the "template" rather than the 
actual result.

For example... let's suppose we have a "famous art works" widget. 
Someone creates a huge list of famous artworks by title.  When 
triggered, it gives back a thumbnail of that artwork, a short snippet 
from Wikipedia, and links to 3-5 major art websites with quality 
content.  Niiiiice.

And then, a new major art site comes online.  Someone notices it and 
wants to add it... not by going to 50,000 famous artworks and editing 
the item one by one, but by editing the *template*.

(This probably necessitates that the website in question needs to have a 
url structure which would allow predictable linking... but that's their 
job!)

--Jimbo


From jeremie at jabber.org  Tue Aug 12 08:20:48 2008
From: jeremie at jabber.org (Jeremie Miller)
Date: Tue, 12 Aug 2008 03:20:48 -0500
Subject: [search-ui] some experimental bits
Message-ID: <4AF0F24C-FB5D-49FE-96B9-91E892F5AE55@jabber.org>

Played with an accordion style result, spent too much time just  
finding the js to do it and at then not enough time making it work  
smoothly, but you'll get the general idea:
	http://re.search.swlabs.org/BEWARE2/exp/accordion.html

Updated the "light" experiment by simply doing a float left, resize  
your browser and watch it all reflow, is really intriguing IMO:
	http://re.search.swlabs.org/BEWARE2/exp/light.html#apple

Jer


From aaron.wright at gmail.com  Tue Aug 12 08:29:54 2008
From: aaron.wright at gmail.com (Aaron Wright)
Date: Tue, 12 Aug 2008 04:29:54 -0400
Subject: [search-ui] some experimental bits
In-Reply-To: <4AF0F24C-FB5D-49FE-96B9-91E892F5AE55@jabber.org>
References: <4AF0F24C-FB5D-49FE-96B9-91E892F5AE55@jabber.org>
Message-ID: <d0fd42530808120129r38da7c97mff1fe872c9295228@mail.gmail.com>

I really like the multiple column results.  Maybe we could make an
option to allow users to toggle between single and multiple columns.

--Aaron

On Tue, Aug 12, 2008 at 4:20 AM, Jeremie Miller <jeremie at jabber.org> wrote:
> Played with an accordion style result, spent too much time just
> finding the js to do it and at then not enough time making it work
> smoothly, but you'll get the general idea:
>        http://re.search.swlabs.org/BEWARE2/exp/accordion.html
>
> Updated the "light" experiment by simply doing a float left, resize
> your browser and watch it all reflow, is really intriguing IMO:
>        http://re.search.swlabs.org/BEWARE2/exp/light.html#apple
>
> Jer
>
> _______________________________________________
> Search-UI mailing list
> Search-UI at wikia.com
> http://lists.wikia.com/mailman/listinfo/search-ui
>

From balinny at gmail.com  Tue Aug 12 14:31:30 2008
From: balinny at gmail.com (Balinny)
Date: Tue, 12 Aug 2008 16:31:30 +0200
Subject: [search-ui] some experimental bits
In-Reply-To: <4AF0F24C-FB5D-49FE-96B9-91E892F5AE55@jabber.org>
References: <4AF0F24C-FB5D-49FE-96B9-91E892F5AE55@jabber.org>
Message-ID: <48A19EC2.8040902@gmail.com>

Jeremie Miller wrote:
> Played with an accordion style result, spent too much time just  
> finding the js to do it and at then not enough time making it work  
> smoothly, but you'll get the general idea:
> 	http://re.search.swlabs.org/BEWARE2/exp/accordion.html
>   
I have a doubt. How do you visit the results there? There's a link to 
the page in the title (i see it on the status bar) but click on it just 
folds/unfolds the description...


From jeremie at jabber.org  Tue Aug 12 17:21:46 2008
From: jeremie at jabber.org (Jeremie Miller)
Date: Tue, 12 Aug 2008 12:21:46 -0500
Subject: [search-ui] some experimental bits
In-Reply-To: <48A19EC2.8040902@gmail.com>
References: <4AF0F24C-FB5D-49FE-96B9-91E892F5AE55@jabber.org>
	<48A19EC2.8040902@gmail.com>
Message-ID: <FD3400C5-66B2-4CBA-AEDE-2874DF17892D@jabber.org>

>> 	http://re.search.swlabs.org/BEWARE2/exp/accordion.html
> I have a doubt. How do you visit the results there? There's a link to
> the page in the title (i see it on the status bar) but click on it  
> just
> folds/unfolds the description...

Yeah, it's just an experiment, wasn't sure if it was worth cleaning up  
and making usable, it's open source so I suppose if someone likes it  
they've got some obvious things to fix right away :)

Jer


From jeremie at jabber.org  Tue Aug 12 17:23:57 2008
From: jeremie at jabber.org (Jeremie Miller)
Date: Tue, 12 Aug 2008 12:23:57 -0500
Subject: [search-ui] some experimental bits
In-Reply-To: <d0fd42530808120129r38da7c97mff1fe872c9295228@mail.gmail.com>
References: <4AF0F24C-FB5D-49FE-96B9-91E892F5AE55@jabber.org>
	<d0fd42530808120129r38da7c97mff1fe872c9295228@mail.gmail.com>
Message-ID: <CF41178D-7123-45FE-A949-27864A82CD5A@jabber.org>

> I really like the multiple column results.  Maybe we could make an
> option to allow users to toggle between single and multiple columns.

I do as well, and if we figure out a better way to show the mouseover  
menu (which takes up a lot of margin space) then yeah it's just some  
CSS so it could be fairly easily integrated into the current result UIs.

Jer


From rainer.blome at gmx.de  Sat Aug 16 21:12:55 2008
From: rainer.blome at gmx.de (Rainer Blome)
Date: Sat, 16 Aug 2008 23:12:55 +0200
Subject: [search-ui] HTML comment instead of newline at end of .html files?
Message-ID: <48A742D7.4010303@gmx.de>

At the end of many or all HTML files in re.search there is no newline.
Instead, after the '>' of '</html>', there is this (quotes excluded):
'

<!--




-->'

Is this intentional?  What is the purpose of this?
Why is there no terminating newline?

Rainer


From rainer.blome at gmx.de  Sat Aug 16 21:42:40 2008
From: rainer.blome at gmx.de (Rainer Blome)
Date: Sat, 16 Aug 2008 23:42:40 +0200
Subject: [search-ui] Warning regarding "background-color:none;"
Message-ID: <48A749D0.5070201@gmx.de>

For the URL http://re.search.swlabs.org/recent.html Seamonkey complains 
in the script console:

Warning: Expected color but found 'none'.  Error in parsing value for 
property 'background-color'.  Declaration dropped.
Source File: http://192.168.1..../.../cool/kt_files/global_changes.css
Line: 86

Line 86 currently looks like this:

	background-color:none;

"none" is not a valid value for "background-color".
"none" is a valid value for "background-image".
"transparent" is a valid value for "background-color".

Since I don't really know CSS, and don't know the intent of this line,
I don't know how to fix this.
The line is part of ".rating-count img {..}".
If no background color is desired, that line should be left out, 
shouldn't it?

Rainer


PS: For the same page, there is another warning, but that was easy to 
fix.  The cause is a missing left brace:

Warning: Expected identifier for pseudo-class or pseudo-element but 
found '11px'.  Ruleset ignored due to bad selector.
Source File: http://re.search.swlabs.org/kt_files/style.css
Line: 182

.blurb
	font-size:11px;
	cursor:pointer;
	color:#49499a;
}

From rainer.blome at gmx.de  Sat Aug 16 23:57:36 2008
From: rainer.blome at gmx.de (Rainer Blome)
Date: Sun, 17 Aug 2008 01:57:36 +0200
Subject: [search-ui] svn lock on cool/search.html?
Message-ID: <48A76970.2000600@gmx.de>

As discussed in chat, I added <script src="[../]js/i18n/i18n.js">
to the HTML files that need it (all that use header.js).

For some reason, I could not commit the changes as a whole.
There seems to be some kind of lock in svn on cool/search.html.

Committing the rest, without search.html, worked.
See below for the failed commit (I tried it twice, with about ten 
minutes in between).

Trying to commit just cool/search.html fails with a similar message
(see at the bottom).

Rainer


sh-3.2$ svn update
U    cool/kt_files/style.css
U    cool/kt_files/structure.css
A    cool/exp/hits.html
U    cool/js/ac.js
Updated to revision 480.

sh-3.2$ svn ci -m 'Added to most HTML files: <script 
src="[../]js/i18n/i18n.js">.
This treats i18n.js like the other .js files, instead of loading it 
"dynamically" via servertouse.js.'
 > Sending        cool/JSON/messageusersform.html
Sending        cool/JSON/reportbugform.html
Sending        cool/about/about.html
Sending        cool/about/contact.html
Sending        cool/about/crawl.html
Sending        cool/about/get_involved.html
Sending        cool/about/toolbar_thankyou.html
Sending        cool/activity.html
Sending        cool/addrel.html
Sending        cool/avoid.html
Sending        cool/background.html
Sending        cool/board.html
Sending        cool/editpicture.html
Sending        cool/editprofile.html
Sending        cool/editrel.html
Sending        cool/exp/autocomplete.html
Sending        cool/find.html
Sending        cool/friend_search.html
Sending        cool/friendsactivity.html
Sending        cool/fun/bloom.html
Sending        cool/fun/clippy.html
Sending        cool/fun/favicon.html
Sending        cool/fun/fun.html
Sending        cool/fun/keys.html
Sending        cool/fun/live_changes.html
Sending        cool/fun/mapped_changes.html
Sending        cool/fun/micro.html
Sending        cool/fun/texter.html
Sending        cool/help/contact.html
Sending        cool/help/email_contacts.html
Sending        cool/help/help.html
Sending        cool/help/help_profile.html
Sending        cool/help/overview.html
Sending        cool/help/reportbug.html
Sending        cool/help/toolbar.html
Sending        cool/index.html
Sending        cool/invite.html
Sending        cool/invite_advanced.html
Sending        cool/legal/copyright.html
Sending        cool/legal/legal.html
Sending        cool/legal/privacy.html
Sending        cool/login.html
Sending        cool/main_search.html
Sending        cool/mayknow.html
Sending        cool/metrics/actiontrend.html
Sending        cool/metrics/actiontrends.html
Sending        cool/metrics/friendships.html
Sending        cool/metrics/metrics.html
Sending        cool/metrics/newusers.html
Sending        cool/metrics/photouploads.html
Sending        cool/metrics/pokes.html
Sending        cool/metrics/profileupdates.html
Sending        cool/metrics/queries.html
Sending        cool/metrics/querytrends.html
Sending        cool/metrics/searchactions.html
Sending        cool/metrics/statusupdates.html
Sending        cool/metrics/topusers.html
Sending        cool/metrics/wallposts.html
Sending        cool/metrics.html
Sending        cool/mutual_rel.html
Sending        cool/newusers.html
Sending        cool/notifications.html
Sending        cool/profile.html
Sending        cool/recent.html
Sending        cool/register.html
Sending        cool/rel.html
Sending        cool/removerel.html
Sending        cool/search.html
Sending        cool/toolbar/download.html
Sending        cool/tools/mostcontributions.html
Sending        cool/tools/mostqueried.html
Sending        cool/tools/recentcontributions.html
Sending        cool/tools/recentqueries.html
Sending        cool/tools/trends.html
Sending        cool/tools/wantedresults.html
Sending        cool/viewrelrequests.html
Transmitting file data 
...............................................svn: Commit failed 
(details follow):
svn: PUT of 
'/re.search/!svn/wrk/fb4fd570-6bec-11dd-93b0-535933c9aebd/cool/search.html': 
423 Locked (http://svn.swlabs.org)

sh-3.2$ svn info cool/search.html
Path: cool/search.html
Name: search.html
URL: http://svn.swlabs.org/re.search/cool/search.html
Repository Root: http://svn.swlabs.org/re.search
Repository UUID: e5e9b3c0-802f-4357-b5e5-916671d6c50f
Revision: 480
Node Kind: file
Schedule: normal
Last Changed Author: aaron
Last Changed Rev: 259
Last Changed Date: 2008-06-16 20:51:50 +0200 (Mon, 16 Jun 2008)
Text Last Updated: 2008-08-06 01:03:54 +0200 (Wed, 06 Aug 2008)
Checksum: 1d9523ec0090f33717e58331cac9895f

sh-3.2$ svn ci -m 'Added to search.html: <script src="js/i18n/i18n.js">.
This treats i18n.js like the other .js files, instead of loading it 
"dynamically" via servertouse.js.' cool/search.html
 > Sending        cool/search.html
Transmitting file data .svn: Commit failed (details follow):
svn: PUT of 
'/re.search/!svn/wrk/cf817d02-6bee-11dd-8253-11a6b9e46841/cool/search.html': 
423 Locked (http://svn.swlabs.org)

From balinny at gmail.com  Sun Aug 17 22:43:12 2008
From: balinny at gmail.com (Balinny)
Date: Mon, 18 Aug 2008 00:43:12 +0200
Subject: [search-ui] svn lock on cool/search.html?
In-Reply-To: <48A76970.2000600@gmx.de>
References: <48A76970.2000600@gmx.de>
Message-ID: <48A8A980.2050409@gmail.com>

Rainer Blome wrote:
> sh-3.2$ svn ci -m 'Added to search.html: <script src="js/i18n/i18n.js">.
> This treats i18n.js like the other .js files, instead of loading it 
> "dynamically" via servertouse.js.' cool/search.html
>  > Sending        cool/search.html
> Transmitting file data .svn: Commit failed (details follow):
> svn: PUT of 
> '/re.search/!svn/wrk/cf817d02-6bee-11dd-8253-11a6b9e46841/cool/search.html': 
> 423 Locked (http://svn.swlabs.org)
Strange. The client doesn't report it as locked, but it is:
Error: Path '/cool/search.html' is already locked by user 'aaron' in 
filesystem '/export/svn/re.search/db'

I have stolen the lock and unlocked it.
As it has been more than a month since last change, i assume it was an 
error.


From kubes at apache.org  Mon Aug 18 20:12:06 2008
From: kubes at apache.org (Dennis Kubes)
Date: Mon, 18 Aug 2008 15:12:06 -0500
Subject: [search-ui] Wikia Search Toolbar Internationalization
Message-ID: <48A9D796.80101@apache.org>

All,

I have setup a wiki page for internationalization of the wikia search 
toolbar at:

http://search.wikia.com/wiki/Toolbar_Translations

There are currently about 25 different text strings that need to be 
translated per language.  If there is a desire to have the toolbar in 
any language other than english please create a section on the wiki page 
for that language.  Once the text resources are translated and reviewed 
by the community we can include them into the toolbar.

Please let me know if there are any questions or if I have missed anything.

Dennis

From jeremie at jabber.org  Mon Aug 18 22:29:17 2008
From: jeremie at jabber.org (Jeremie Miller)
Date: Mon, 18 Aug 2008 17:29:17 -0500
Subject: [search-ui] something to try and avoid?
Message-ID: <553B6908-ADC6-4994-B888-A0ACE99CFD7A@jabber.org>

http://sethgodin.typepad.com/seths_blog/2008/08/the-dead-zone-o.html

When it comes to UI, I'm personally only capable of making something  
on the far left, and strive to imagine things on the far right, and  
sometimes I might end up in the middle, all of which are apparently  
the worst places to be, *grin*...

Jer
  

From aaron.wright at gmail.com  Mon Aug 18 23:46:45 2008
From: aaron.wright at gmail.com (Aaron Wright)
Date: Mon, 18 Aug 2008 19:46:45 -0400
Subject: [search-ui] something to try and avoid?
In-Reply-To: <553B6908-ADC6-4994-B888-A0ACE99CFD7A@jabber.org>
References: <553B6908-ADC6-4994-B888-A0ACE99CFD7A@jabber.org>
Message-ID: <d0fd42530808181646q14416eddm4d3ef91031734bc6@mail.gmail.com>

I think we have done a good job avoiding that.  I think we are in the
middle of the left curve.  If we continue to try to minimize the use
of graphics, we should stay there.  Graphics pull you to the far
right.

--Aaron

On Mon, Aug 18, 2008 at 6:29 PM, Jeremie Miller <jeremie at jabber.org> wrote:
> http://sethgodin.typepad.com/seths_blog/2008/08/the-dead-zone-o.html
>
> When it comes to UI, I'm personally only capable of making something
> on the far left, and strive to imagine things on the far right, and
> sometimes I might end up in the middle, all of which are apparently
> the worst places to be, *grin*...
>
> Jer
>
> _______________________________________________
> Search-UI mailing list
> Search-UI at wikia.com
> http://lists.wikia.com/mailman/listinfo/search-ui
>

From jeremie at jabber.org  Sat Aug 23 20:29:32 2008
From: jeremie at jabber.org (Jeremie Miller)
Date: Sat, 23 Aug 2008 15:29:32 -0500
Subject: [search-ui] another experimental UI
Message-ID: <E26990EA-0FC0-49F6-9FC8-D7F7F424ABF2@jabber.org>

This is just a tweak of the light.html to show results in multiple  
columns and include an osx-style dock that can be used for high level  
controls.

	http://re.search.swlabs.org/BEWARE2/exp/dock.html#just%20testing

Enter a new search term by clicking on any of the four left icons, and  
in firefox the right-most icon will just change the result width class  
to 200px (double the columns).

It's interesting to use, but all the results shown like this is almost  
overkill and there needs to more "scent" of the individual results to  
distinguish them... was fun to make though!

Jer




From aaron.wright at gmail.com  Mon Aug 25 01:10:13 2008
From: aaron.wright at gmail.com (Aaron Wright)
Date: Sun, 24 Aug 2008 21:10:13 -0400
Subject: [search-ui] another experimental UI
In-Reply-To: <E26990EA-0FC0-49F6-9FC8-D7F7F424ABF2@jabber.org>
References: <E26990EA-0FC0-49F6-9FC8-D7F7F424ABF2@jabber.org>
Message-ID: <d0fd42530808241810x39988b24j607d8a76ea486186@mail.gmail.com>

I really like this.  I think it's very easy to find the info you want.
 It feels very comfortable to use, maybe because I have a mac.  I am
curious what others think.

--Aaron

On Sat, Aug 23, 2008 at 4:29 PM, Jeremie Miller <jeremie at jabber.org> wrote:
> This is just a tweak of the light.html to show results in multiple
> columns and include an osx-style dock that can be used for high level
> controls.
>
>        http://re.search.swlabs.org/BEWARE2/exp/dock.html#just%20testing
>
> Enter a new search term by clicking on any of the four left icons, and
> in firefox the right-most icon will just change the result width class
> to 200px (double the columns).
>
> It's interesting to use, but all the results shown like this is almost
> overkill and there needs to more "scent" of the individual results to
> distinguish them... was fun to make though!
>
> Jer
>
>
>
> _______________________________________________
> Search-UI mailing list
> Search-UI at wikia.com
> http://lists.wikia.com/mailman/listinfo/search-ui
>

From phil.nelson at gmail.com  Mon Aug 25 01:16:37 2008
From: phil.nelson at gmail.com (Christian Nelson)
Date: Sun, 24 Aug 2008 21:16:37 -0400
Subject: [search-ui] another experimental UI
In-Reply-To: <d0fd42530808241810x39988b24j607d8a76ea486186@mail.gmail.com>
References: <E26990EA-0FC0-49F6-9FC8-D7F7F424ABF2@jabber.org>
	<d0fd42530808241810x39988b24j607d8a76ea486186@mail.gmail.com>
Message-ID: <E8FA334B-2B24-4B8F-AE53-F1757E82FC8E@zerolives.org>

What would the dock controls be used for?

- Phil

On Aug 24, 2008, at 9:10 PM, Aaron Wright wrote:

>> This is just a tweak of the light.html to show results in multiple
>> columns and include an osx-style dock that can be used for high level
>> controls.


From aaron.wright at gmail.com  Mon Aug 25 01:32:57 2008
From: aaron.wright at gmail.com (Aaron Wright)
Date: Sun, 24 Aug 2008 21:32:57 -0400
Subject: [search-ui] another experimental UI
In-Reply-To: <E8FA334B-2B24-4B8F-AE53-F1757E82FC8E@zerolives.org>
References: <E26990EA-0FC0-49F6-9FC8-D7F7F424ABF2@jabber.org>
	<d0fd42530808241810x39988b24j607d8a76ea486186@mail.gmail.com>
	<E8FA334B-2B24-4B8F-AE53-F1757E82FC8E@zerolives.org>
Message-ID: <d0fd42530808241832r63c359eic4421e3e817399fa@mail.gmail.com>

The dock controls could be used for all of the internal navigation.
For example, Communtiy, Profile, Tools, Recent Changes, could all have
icons at the bottom for navigation to other parts of the site.

What I like is that the results are right at the top.  The three
column layout might be a bit too much info overload.  Maybe two
columns with some space in the middle might be better.

--Aaron

On Sun, Aug 24, 2008 at 9:16 PM, Christian Nelson <phil.nelson at gmail.com> wrote:
> What would the dock controls be used for?
>
> - Phil
>
> On Aug 24, 2008, at 9:10 PM, Aaron Wright wrote:
>
>>> This is just a tweak of the light.html to show results in multiple
>>> columns and include an osx-style dock that can be used for high level
>>> controls.
>
> _______________________________________________
> Search-UI mailing list
> Search-UI at wikia.com
> http://lists.wikia.com/mailman/listinfo/search-ui
>

From beesley at gmail.com  Mon Aug 25 03:41:06 2008
From: beesley at gmail.com (Angela)
Date: Mon, 25 Aug 2008 13:41:06 +1000
Subject: [search-ui] another experimental UI
In-Reply-To: <d0fd42530808241810x39988b24j607d8a76ea486186@mail.gmail.com>
References: <E26990EA-0FC0-49F6-9FC8-D7F7F424ABF2@jabber.org>
	<d0fd42530808241810x39988b24j607d8a76ea486186@mail.gmail.com>
Message-ID: <8b722b800808242041s2b0e13afy477d871b5b757558@mail.gmail.com>

On Mon, Aug 25, 2008 at 11:10 AM, Aaron Wright <aaron.wright at gmail.com> wrote:
> I really like this.  I think it's very easy to find the info you want.
>  It feels very comfortable to use, maybe because I have a mac.  I am
> curious what others think.

I've not used a mac for years and this didn't really make sense to me.

Angela