Judging Links project idea

A while back I tried to start another open source project that I wanted to call Judging Links, which is about setting up a website that takes user suggestions for good webpages, and also has users who judge the picked sites, and a voting option for visitors which is used for administration of the linkers and judgers in a completely automated way.

Yup a bit of an ambitious project which I actually had up on Java.net as a project, as I hoped to mainly architect it and bring in a bunch of others to code, but I kind of stumbled on the recruitment, and gave up on the project before any code was written.

But I thought to myself, well, at least I can put it on my programming blog! So here is something from an early project document I started when trying to get things before. I didn't get a lot down, but it has the gist of it.

What is Judging Links?

The Internet offers the possibility of leveraging the efforts of many people from all over the world to find the best information. However, that capability is yet to be fully utilized while several projects like the Wikipedia have made substantial progress. The Judging Links project aims to fully leverage the power of the Internet to connect people by allowing people called Linkers to suggest websites, and people called Judgers to determine the value of those sites, to create a web portal that will have the best of the web. This is a working manual that will provide a guide. Developers will edit this document as the project develops, and it is to be the primary development document.

People like to recommend and at its heart the project is about letting people who like to find things they like and recommend them to others operate with full freedom.
However, the reality is that what one person likes, many others may dislike, so there are people who supply the critical category, and, of course, there are usually plenty of people willing to criticize!

How it all works

The primary mission of development is simply providing a way for people to do what they do best with a minimum of fuss, while allowing management without a lot of developer involvement.

That mission defines the project and keeping it in mind is paramount for success. Users need to have a seamless experience where if they are recommending a link it’s easy and straightforward and if they are judging links, it is easy as well.
Simplicity is best.

Linkers and Judgers

The Linkers will have the option of recommending links to websites in various categories, with the requirement that they write a short description which tells what the link is about and why it’s a great link. That means that to be a good Linker a person will have to be able to not only find good links, but write well also. The two requirements go together, as it’s important that a Linker know why they’re recommending a particular link, and having to write about why, helps.

The Judgers will have their own categories where they specialize with an option to also do some critiquing in off-categories.

And that's all I had, where I did some editing to clean up some things as it was uglier than I remember. Well, I had just started.

Here's a bit more from another early planning doc.

The project would create a framework and beta implementation with a front end GUI for primary views, and two internal GUI's for superusers who after registering would either be able to suggest websites, or judge suggestions. Linkers would have their sites face judgement from the Judgers who would be judged by the overall site's success.

The front-end of the project will contain links to websites under maybe 5 categories as I don't like webpages that are full of stuff.

Under each category there will be 5 top sites, and 5 middle sites, where the order comes from ratings by the Judgers, while the sites are given by the Linkers.

The main front-end allows any user to give feedback on overall quality like with options to click good, bad, really crappy, or great links!

That minimizes fraud by making the easy input come from anybody while the real work is done internally, and hopefully there would be enough site visitors such that Judgers couldn't elevate themselves, but hey, if they can, then why not?

If they have good sites, then they have good sites.

Judgers can judge in only 2 of the 5 categories and depending on how well their categories do, the bottom 25% or 50% are dropped over any particular quarter.

That guarantees a lot of turnover in the judging field. Linkers are turned over by the Judgers.

Linkers whose sites are consistently judged poor are judged down, while for good sites they are rated up.

Their max rating is 3, if they're judged down below 0, they're out.

There are 3 categories for linkers:

New Linker
Linker
Super Linker

People can opt out of being a linker at any time, or they can get kicked out if they're not performing.

Judgers have a max rating of 3 as well. But rate higher based on longevity, and just get a title, as if they are in the bottom 50% or 25% depending on which is getting tossed, their rating doesn't matter.

Judgers have 3 categories as well:

New Judge
Judge
Supreme

Judges can opt out at any time, or they can be kicked out based on their overall site performance.

I don't think it matters if people try to be both a Judger and a Linker at the same time for any reason like to try and help themselves as the job should be hard enough that if anyone can pull it off, more power to them.

Amazingly enough, people will work hard in a fair system, without getting paid.

People kicked out are x-Linkers or x-Judgers, and who cares if they sneak back in under a new ID as they have to perform.

Most of the project development will be on the database for managing information, and on the GUI's for ease of use, and to minimize the possibility for fraud.

Opportunities within the project abound for data management, GUI development, and utilization of distributed resources.

It's kind of pie in the sky but if successful the idea would be a real interactive way to dynamically get the best websites that could rival methods used by the current big players.

Yeah, that was a lot more detailed. So the idea is out there. Maybe someday I'll come back to this, but for now, at least it's on my blog.


James Harris

Next step?

At times I wonder about how I might add new features to Class Viewer and one thing that seems obvious would be to have the possibility of opening up an editor and going to a method, to actually fiddle with the code, if you had the source code, like if it were your own project you were looking over.

But do current editors allow calls to them with a location within a program? I don't know.

If they do then coding that would be relatively easy and then I could just add something more to the packagedirectory.xml (or maybe create new xml file?) where you tell it what editor you use, and away it could go.

But that is just light musings at this point as development is still mostly on hiatus, but I'm starting to think I might do something more within the next six months or year.


James Harris

Why a quick reference tool?

To me having a quick reference tool is just a very nice thing when you're programming as you can very quickly get some quick information--often just to jog your memory--and do so without a lot of effort, like waiting for some big program to load, or being forced to follow some template or have some auto-sense shadowing whatever you type.

I got excited about Class Viewer, the prototype, way before I had a SourceForge project, when I thought about the case insensitive search on methods, where I could just put in a bit of a method name, or put in something like "char" to pull out all methods that had "char" in them, whether they took chars or returned chars, or whatever, as I just hadn't seen that yet in other tools.

And javadocs, for some reason, as important as javadocs are, and despite Sun having produced a nice generic framework for accessing javadocs to the method, it can be a pain keeping up with them.

But if you're doing a quick reference, get a method, but are not sure that it's exactly the method you want, don't you want immediately to see the javadocs to clear that up?

Why should it not be a fluid process that follows the developer's needs?

Well, it can be, and that's what you get with Class Viewer.

It encapsulates a special problem space for the Java developer--quickly looking up basic information about a class, searching on methods, and then, if necessary, getting immediately to javadocs, and that's the problem space.

I used two big windows so that you could easily see the methods to one side as a constant, and get results on the other side, as well as get to, if you need them, constructors and fields.

A tool like Class Viewer by making it easy for people to get to javadocs gives developers greater reason to write them and write them well knowing that people are going to be using them, as it's so easy.

So that's a lot of the concept. Ease of use, quickness and functionality are the ideas behind Class Viewer, where it's supposed to be lightweight, useable in a wide variety of areas, without forcing you to have to get a manual to figure out how to use it fully.


James

Class Viewer Basics

Class Viewer is made to be run from the command line, so you can put the ClassViewer.jar in the classpath, or compile the source and put that in the classpath, and run from the command line with something like:

java com.jstevh.viewer.ClassViewer String

which will open up with the class java.lang.String, or you can just use:

java com.jstevh.viewer.ClassViewer

to open up the GUI that I also call a UEI (User Enabling Interface) blank and type in a class name there.

When not ran as an applet, ClassViewerConfig.xml needs to be in the folder from which you are operating, which means you can have the jar file wherever you want, and different ClassViewerConfig.xml files in folders from which you run the program.

For instance, if you are in /home/research/myresearch and you run Class Viewer from there, you'd need a ClassViewerConfig.xml file in that myresearch folder.

If you run Class Viewer as an applet or directly from the executable jar, you won't be able to select your own classes as they won't be in the classpath.

You can double-click on methods in the left big window to do a search on them, which shows up in the "Results" big window to the right, and then you can double-click on a method there to go to javadocs to that method.

To get inherited methods you have to do a search from the search box in the lower right, and double-clicking on them will just bring you to javadocs at the top of the class.

All searches are case insensitive, and the search from the search box is space delimited.


James

Edited to change packagedirectory.xml to ClassViewerConfig.xml on 7/29/2015, ___JSH

Considering the GUI

One the things I did deliberately with Class Viewer--which is why open source is such a nice paradigm as you can try new things--is get away from the "File", "Edit", "View" type of menu at the top. So I have "Help" first, and then "Links", and for when it's not in applet mode, "ClassPath".

To me that's just a more natural way for the menu to go, and I like to think that I managed a fairly decent design for a program I long thought of as a prototype.

The design of Class Viewer is meant to lead you to using it intuitively, without needing a lot of instruction or lots of menu items, as you can type in a class, and then just use the the mouse, and get all the way to javadocs to a particular method.

I decided to call it a User Enabling Interface, or UEI.

The way Class Viewer is designed, there just isn't much configuration, and it gets all of its changeable information, like where packages are, or what browser you're using, from packagedirectory.xml, so the program is fairly static.

I like to say that as long as the format for getting javadocs doesn't change, and the Reflections api isn't broken with previous versions, Class Viewer can be used indefinitely, as you can simply change the xml file, which means that I could stop development now, and feel confident that several years from now, Class Viewer could still be used.

My design focus is on an easy to use design that doesn't force me to keep fiddling with things to do something, and which doesn't make me go through a lot of options, as I think a proper design, for a properly encapsulated problem solution, will not require a lot of effort just figuring out how to get it all to work.

If you need a lot of options, I think you need a separate module or another program that might be called by your app (and I'm considering what else to add to Class Viewer where it would call another program), versus forcing people to spend time understanding a particular design.

James