Topic: ARIS - Archive Retrieval Interface Systems (Ideas) (Page 1 of 1)

OK, that's a pretty weird thread title, and you're probably scratching your head right now, wondering what I am talking about. In brief (this is Suho-style brief we're talking about, of course), I've long thought about changing the way I display the archive of entries at Liminality. The longer the chronological list of entries gets, the more useless it becomes. I first contemplated doing the category thing like everyone else, but I had a hard time pigeonholing my entries. So I came up with the idea of topics (this was before the tag meme exploded on the net--not to say that I was anywhere close to the first person to think of this, of course). Displaying categories is easy. You just have a user click on a category link and display all the entries in that category. You could, of course, do the same thing with topics--have the user click on a link and then display all entries that have that topic. With most entries getting multiple topics, though, it would kind of be a waste of the system to just do one topic at a time. Let's say, for example, that a visitor to my site wants to see all of my entries that deal with pickles and windsurfing, but do not address the topic of furry animals. I need an interface to allow the visitor to choose what he or she wants to see.

This is where the archive retrieval interface system (ARIS - I just love acronyms, don't you?) comes in. I've been thinking about this for a while, and I've finally decided to put it into motion. Not that this project will be completed any time soon, but I figure if I don't start sometime, it will never get done. Anyway, I currently have four possible ideas for ARISs. Rather than try to explain these ideas, I've done a very messy mockup of them. Go take a quick look at these (otherwise the rest of the post will make no sense--i.e., even less sense than the first part of the post). This is just a mockup, obviously--none of the forms are functional.

Version 1 is the simplest both in terms of implementation and usability (I think). Of course, it is limited, since I have to decide between applying the AND operator or the OR operator universally, depending on whether I want a restrictive search or inclusive search. I'm thinking OR is probably the way to go.

Version 2 appeals to the geek in me because it allows the user to choose between AND, OR, and NOT for each and every topic. It provides the most functionality, but it is probably the least usable. I'm concerned that users might not understand how it works, and it is unwieldy both in terms of code and actual use.

Version 3 was actually my original idea from way back when. Disadvantages include an artificial limit imposed on the number of possible terms as well as possible confusion with the operators. For example, if the user selects "Topic 1 OR Topic 2 AND Topic 3," do they mean (1 || 2) && 3 or do they mean 1 || (2 && 3)? I could follow the logical order, but the potential for confusion is great.

Version 4 is a compromise of sorts. There is still the artificial limit on the number of possible terms, but it might be less confusing than v.3.

These examples only show five topics, but the final version will probably have closer to twenty, so that's another thing to keep in mind.

Hah! How's that for brief? Anyway, questions, comments, double entendres, etc. are welcome.

___________________________
Suho: www.liminality.org | Cell 270 | Sig Rotator | the Fellowship of Sup

(Edited by Suho1004 on 05-18-2005 12:05)

I'd take a deep look at boolean searches before deciding on any special way to go, example here http://library.albany.edu/internet/boolean.html

May I ask how much is this "I want to do it to learn" and how much is "I want this up and running to get the functionality on my site"

That will probably steer you in the "right" way to do this, if you only want it "up there" you can plug in a search engine of some sort and you are done.

If your primary goal is to learn the principles and create a great new interface for this type of functionality research around search engines and their implementation of this in the interfaces is probably the order of the day.

/Dan

{cell 260} {Blog}
-{ ?There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. - Jeremy S. Anderson" }-

Thanks for the link. I'm fairly familiar with Boolean logic, but it's nice to have a refresher.

As for why I want to do this, well, I would say it's a combination of a desire to learn and a desire to get the functionality. I'm kind of a do-it-yourselfer--everything on my site was either done by me or done by me with much help from kind individuals (e.g., the style-switching mechanism). The idea of simply plugging in a pre-fab search engine (especially since I don't really need all the functionality of a search engine) is not all that appealing to me. I know there is the whole "reinventing the wheel" concern, but sometimes you need to at least modify the wheel to fit your needs.

My main goal is to get something working that takes advantage of a topic system but is intuitive and easy to use. Not that it necessarily has to be simple, of course, just not complicated. While part of me is really tempted to geek out and create a monster, this is ultimately for the people who visit my site, not me.

I will take a look at search engine technology and implementation to see what's being done. Thanks for the tips and advice.

___________________________
Suho: www.liminality.org | Cell 270 | Sig Rotator | the Fellowship of Sup

No prob, it's an interesting topic indeed
Personally I'm all for the one field version where you can add words one by one and it defaults to:
XXX AND YYY AND ZZZ

to get OR you actually write XXX OR ZZZ

if you do XXX -YY it's XXX but NOT YY

id you do XXX +YY it is XXX AND YY AND within the same file/document


A simple form and a brief and logical explanation and I'm a happy searcher
/Dan

{cell 260} {Blog}
-{ ?There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. - Jeremy S. Anderson" }-

quote:

---

DmS said:

A simple form and a brief and logical explanation and I'm a happy searcher

---

That sounds like the key to it all. I'll keep that in mind.

I have a presentation due next week (Wednesday), so I doubt I'll make any progress on this before then, but I'd be happy to hear what others might have to say on the subject.

___________________________
Suho: www.liminality.org | Cell 270 | Sig Rotator | the Fellowship of Sup

As far as I know in the boolean searching scheme, preceeding a term with AND makes it a required term, where as putting OR between two terms makes them optional. So, if you use 'TERM 1 OR TERM 2 AND TERM 3', your engine should search for documents containing either 'Term 1 and Term 3' OR 'Term 2 and Term 3', and if it contains either of them, then it's returned as a match. Now, as for ranking them...


Justice 4 Pat Richard

Wow, what a surprise to see this topic come back up. Thanks for the tips, though.

This project has been placed on the back burner for now, due to other demands on my time, I hope to move my site over to a database soon (right now I use flat files), and I will probably implement this idea at that time. Not sure when i'll actually have time to do this, though...

___________________________
Suho: www.liminality.org | Cell 270 | Sig Rotator | the Fellowship of Sup