Bitzi
home of the
Bitpedia
digital media encyclopedia

About, Products, Download, Search, Browse, Discuss, BitSocieties, Help



Bitzi works
best with Bitzi-Powered Applications.
Register or Sign In 

Bitzi General Discussion: Reflections

Main Site : bboard : Bitzi General Discussion : One Message

Message:

Reflections   [forward as email]
Dear All,

As a recently joined member and having added a few files and "bitprints", I wanted to take a few moments to reflect on what I've learned. I must firstly praise the worthy concept behind this site. Inevitably with a note of critique there is a tend to focus on the negative or the deficient and in some ways that isn't fair. The concept and the potential for this site and for the community that it will increasingly serve is enormous and any comments I make here should be seen in the context of an approval and desire to improve and not as stone casting at a poor effort.

This could become the Google of digital media or the so-called "transient web". This is extremely important and the Bitzi developers and the user community can shape that into being. I'm sure Bitzi would be an excellent investment if the liability could be limited and if such investment was being sought. In that light then, I have a few comments.

The web pages are really rather "busy" visually. Lots of advertisements, lots of verbiage. The visual of a ticket is quite cute but the comparison with Google is a valid one. A search page resolutely bland with just a couple of ads at the top or down the right hand side with limited contrast and two or three line search responses in each case. In the context of Bitzi we might then have links that lead to the ticket page but with rather less visual "action" therein. Everybody respects the need for Bitzi to generate advertising revenue but the present layout seems to detract from the usability and that will eventually defeat the goal (not least of the advertiser).

The site itself is very slow. This has been noted before in the forums but I have seemingly lost bitprints to responses like "page timed out" and this does need to be fixed if the level of traffic anticipated is to be maintained. In fact it has taken me hours to submit this message this evening.

I see that rated filenames are promoted over unrated ones even when these arrived first. Perhaps to encourage people to stand by their submissions, anonymous contributors should not be acknowledged as the first contributor on the search page once a non-anonymous one commits?

I have some suggestions for further tags:

1. When someone adds content which they themselves author, they need to be able to notify if that content is then revised. Typically a content item like a document is added, then subsequently a new item is added, and the old version is given a "revised by" tag pointing at the new version, and the new version is given a "revises" tag pointing at the old one.

Clearly we want pristine files on the network and these tags are not meant to encourage people to submit content that is half-baked. But in the real world sometimes revisions are unavoidable and this provides a simple but convenient means to relate files so that people downloading can be assured they are getting the most recent version.

2. Alternatively there could be a means by which arbitrary files can be related along with a reason why. I note that a good attempt at automatically deriving some file relationships is already done on Bitzi. For example by noting when more than one file has the same length and first 20 bytes. I suppose it might be possible to use the related URL feature by pointing at another Bitzi URL. I'm guessing the latter though is designed to enable users to relate further points of interest to the media. Instead perhaps this should simply be a bitprint link, along with a reason for the relationship. Some reasons might be specific options from a drop down list such as the revisions tag above. A previous poster noted a desire to relate tracks on a single CD.

3. Objective description is rather a catch-all term and it isn't immediately clear whether the objective description for a Harry Potter trailer ought to be "Trailer for the Harry Potter Chamber of Secrets film" or "Sorensen video encoded trailer; 2 minutes 5 seconds". I can understand and appreciate the desire not to use arbitrary tags unless it proves absolutely necessary but that means we need to tie down many of the tags explicitly. Full marks for the pop-up help where it appears. This proves a boon when deciding what to include and how to rate.

In the future we want to see much more embedded metadata extracted from the file itself (and I note with satisfaction that at least in the case of audio, a separate hash is kept of the data not including the metadata "track"). With that in mind tags like "Codec(s) used", "Encoder" (the name of the person credited with making the file rather than the content), "Title" (i.e. from the embedded data, not from the filename), "Author" etc. might be very reasonable. Kazaa's most recent version has a very basic set of these for each media type.

4. So far I haven't contributed a huge number of bitprints but what I have added has been mostly films. With this perspective I can see a use for tags like "Play length", "Language" (plus languages for dubbing, subtitling and narration where appropriate), and possibly "Age classification" but I'm not sure how well that would work in practice since it may not be possible to know what rating a downloaded file has unless it's included in the file.

Certainly films have a genre collection all of their own which doesn't seem to be reflected in the current list. http://www-sul.stanford.edu/depts/ts/tsdepts/cat/docs/cat_policy/nonprint/genre.html contains what it amusingly describes as a "basic list" but from there one might cull a decent selection.

5. Documents, programs and possibly multi-part archives will also need a set of metadata. Especially in documents, we will need to maintain a multiplicity of similar metadata. It is typical in professional documents for example to have more than one author listed. We either must fix a way for these to be structured within a tag, or use more than one tag. In the latter case, it must be clearly understood that further tags are supplying more correct data, not correcting previous tags. Presumably the rating system is to be employed for this purpose?

I think the Bitcollider application so far is not at it's full potential although enough has been done now to marvel at how it will shape up in the next few iterations. Adding more hashes (Freenet certainly springs to mind), enabling more file-embedded metadata to be extracted by the tool and permitting users to type some Kazaa-like details in prior to committing are obvious improvements. And perhaps most importantly a Mac OS version, or at least a Java one. A significant amount of "legal" content production is undertaken on these and Silicon Graphics systems and having a port will enable more serious content producers to take part. For an encore there's always a Sherlock plugin...

There are very real and justified reasons why organisations would use file sharing applications instead of or as well as the web, to reduce their bandwidth (by sharing the task of downloading with other sites), to increase reliability (by reducing the single-point-of-failure characteristics of the web) etc. I'll close on the upbeat I opened with, Bitzi is possibly at the forefront of a media revolution. Excellent work and very best wishes for the future.

Now then, about that investment...

mystyc.

 
-- mystyc, May 09, 2003 01:54 pm

Replies:

Re: Reflections   [forward as email]
Thanks for your detailed comments. We hear you -- and agree on just about everything you suggest!

The chief factor limiting more rapid improvement of the Bitzi service is time: all the key continuing contributors are currently employed elsewhere -- in interesting and worthwhile projects! -- so Bitzi is developing slower than we'd like.

Regarding a few of the specifics you've mentioned:

Yes, the Ticket page and search results are in line for visual streamlining. We hope to put the ads that are useful (related products) in a sensible place, and may offer an option for our users to buy a Bitzi free of banner ads.

The slowness is typically when we're hammered by certain patterns of activity -- robots and intensive searches/lists. We can optimize around some of these but are also close to adding more server hardware.

You've also raised some datamodel and UI issues of which we are acutely aware. We know we need to better inject personalities, pride, and a sense of ownership on the ratings and metadata contributions -- such as by better highlighting the first/best contributors of metadata on key files and allowing dedicated users easier ways to "garden" their favorite areas.

All of your suggestions for new tags are things we eventually want to incorporate; for some, the biggest issues are UI-related. If a tag is more than a free-text field, for example a pointer to another exact Ticket, a clean understandable UI for entering and displaying that relationship is tricky.

"Objective Description" and "Subjective Comment" are on the way out, to be merged into a single "Comment" tag for whatever free-form info users think should be added. (We may also add a shared "Wiki" area for each file; do you think that's a good idea?)

The Bitcollider continues to improve with volunteer contributions; an official 0.6 release with new tags and fixes is just pending some small touchup work and an installer build.

We've had several people successfully port most of the Bitcollider to MacOS (esp. OSX), but usually with a few little caveats or without the installer necessary for an official release. Once 0.6 is out we'll find someone to push a MacOS version to release-quality.

We'd love to see a Java Bitcollider -- indeed the very first minimal Bitcollider prototype was in Java -- but improved native and shell-integated versions are going to be ahead of Java on our priority list for quite a while.

If you'd like to talk in further detail about our plans and status, or indeed about investment opportunities, contact me privately.

We can continue discussing these or additional suggestions here or in our Developer forum...

 
-- gojomo, May 12, 2003 08:34 pm

Re: Reflections   [forward as email]
Gojomo,

My original letter started off as a collection of comments about the use of the site generally and not specifically about the process of developing the software. If this starts to become more technical then I stand by your judgement as to whether it should move to the developer forum.

I note your comments on the advertisements issue but stand by my original Google comparison. I do not pay Google to remove banner ads and would not ordinarily appreciate the assumption that I am getting suboptimal Google performance because I haven't forked out. The reality is that Google ads appear on the results page and because they do not flicker at me, and do not have violent contrast, I accept it.

I take the point about the automated hammering from indexing tools. That would certainly explain some of the response time issues. I also see from your reply that you have considered many of the new tag types and are weighing up the best method of presenting those to the user. That's very reassuring - better to delay for a while and get something sensible in use than to rush in and find it untenable.

Is a Wiki overkill? Our opinions on the file itself can be captured in the judgement line (albeit this is rather short) and there isn't much to debate about a file's properties other than that. So I presume it is to be a discussion area about the content? Is it your intent that reviews be attached to the files in the way that say, Amazon attaches user reviews to its sales pages? Or is this user-defined tags by other means?

Your first paragraph suggests that everyone involved on Bitzi is doing it part-time as an adjunct to their normal workload. Is that true? If so I can clearly see how development doesn't move at the rate you would wish. To understand some of the porting issues I too downloaded the source to Bitcollider and compiled it easily for Mac OS X (I was amused when configure "checked my build environment for sanity" - I had visions of my poor laptop being graded from "sane and boring" all the way up to "download strait-jacket.jar"). Nevertheless whilst the command line invokation managed to output the bitprint and other details, it could not then invoke either Mozilla or Safari (a Konqueror derivative).

I'm interested in why you chose not to pursue your Java Bitcollider having got the prototype to work? Was it the perceived overhead of downloading the JRE? On the face of it a Java implementation would:

+ allow you to target more content production platforms;

+ thus generate interest from a greater range of open source developers;

+ ensure no creeping difficulties accrued from different processor types;

+ quickly become a browser-based equivalent that would enable files to be submitted for bitprinting with little or no installation.

Anyway, I'd be interested in your reasoning there.

I would love to see Bitzi succeed. Very best wishes for your efforts.

mystyc.

P.S. Hmm, I seem to be replying to my message and not to yours. I trust this will look right when I submit it!

 
-- mystyc, May 13, 2003 08:06 am

Re: Reflections   [forward as email]
I certainly agree Google is the gold standard for minimal-yet-still-profitable advertising... the only problem is that it takes a lot of runway to get to where they are: time, money, an internal ad sales system, and massive traffic and mindshare.

A big investment could give us the freedom to tone down our ads, or micro-investments from users who'd like an ad-free Bitzi.

The idea of a Wiki-per-file -- and it's still just an idea -- is that there may always be important info that doesn't fit in existing tags, or would be too obscure in other comment fields. So, if there's a small but fairly prominent, world-writable free-text area, devoted users can help get key info across.

Yes, as of right now, all of Bitzi's developers have significant workloads on other projects.

The big reasons to leave the Java prototype behind were size, performance, and desktop integration.

Size: requiring people to download the JRE first, and then launch a JVM every time they wanted to lookup/submit a file would be too much to ask.

Performance: the JVM launch would severely impact the perceived performance of single-file lookups, and for many of the hashes and analyses we want to perform, optimized C code helps a lot. (Note that the JVM itself uses a native SHA1 routine.) Once you have to start mixing in C code, you might as well go all the way.

Desktop integration: To have the handy windows shell right-click "Bitzi Lookup", and for other interesting possibilities we haven't yet implemented, you have to go native... and again, once you start mixing that in, you've left behind enough of the Java benefits you might as well do a full-C implementation.

I prefer Java, but for the quick little utility, we needed something small, fast, and easy to install/run. I'd love to see more full-fledged Java lookup and submission tools developed -- we'd develop them ourselves eventually.

 
-- gojomo, May 15, 2003 08:02 pm
[ Post a reply ]

© 2012 The Bitzi Corporation | Policies | Company Info | In The Press | Link To Us

310,837 bitizens have contributed 19,025,810 tags about 3,778,649 files.