Piotr Gabryjeluk blog

Working On TagFs

tags: dev files filesystem fs fuse python tag

1222457032|%e %B %Y

Today I spent another hour or two on working on tagfs (described in TagFs Idea). It's now pretty much usable. You can now:

browse files with the tag-directory mapping
- directory tag1/tag2/tag3 is the same as tag2/tag3/tag1 or tag3/tag1/tag2
read/write files
- file tag1/tag2/tag3/file is the same as tag2/tag3/tag1/file AND even tag2/tag1,tag3,file
- tags are not only allowed as directory names, but also as comma-separated file prefix
create new files
- echo Some Content > tag1/tag2/some_file
- echo Some Other Content > tag1/tag2,some_file
files have all their "real" properties (owner, group, modification time — this is stored on the back-end filesystem)

Things to do yet:

forbid creating a file with tags rendering some directory with name of existing file
- example: you have tag1/great file
- then you create a tag1/tag2,great,people.txt file
- this way, you would have a great directory showing in the tag1 directory, because there is a file having both tag1 and great
- you also have great file there, so you end up with a file and a directory (tag) of the same name
scan and list files by their properties
- file type — PDF, JPEG, HTML, …
- EXIF tags for JPEG — date taken, camera info
- ID3 tags for MP3 — artist, title, album
improve directory listing
- include SOME files in sub-directories if the sub-directories consist of small number of files
- as a result we get a easily-browsable repository of files
do some marketing
- I would like to serve files from such a file system with FTP or Apache to let people feel the system

I think this experiment is really worth working on this.

In case you want to test the FS, drop me a note or comment.

Comments: 1, Rating: 0

Interesting Shiny Idea Of Michał

tags: dev idea interface wikidot wikidot2

1222368563|%e %B %Y

Now, having Wikidot sending just every form with AJAX and being in early process of planning and developing of Wikidot 2, Michał suggested very nice way to enrich user interface and actually user interaction with modern wiki system.

Two interfaces

Basic HTML

First of all we want to have very simple "basic" interface. This mean serving just the HTML content without any dynamic mechanisms in it. More content — less interface — better for SEO and search bots.

On such a HTML page, there would be one JavaScript file included and responsible for determining if a user is logged in and capable of running the "rich" interface. If this is all true the script redirects the user to the one-page navigation system showing the same content as redirected from.

Rich JavaScript Interface

Such an interface would be one page with some static elements like a top-bar showing who's logged in, new messages and quick link to compose a new one, edit button and probably showing your status on particular site (member/moderator/admin) and link to admin:manage if applicable.

There would go a normal content — the wiki pages. Clicking on any link you would have the UI to load the new page for you. No browser reload thing goes here.

If some page takes really long to load — you have your top-bar still there and can write a PM to someone for example. No need to wait till the browser gets the new content.

More pros:

simpler CSS theme designing — don't worry about the My Account menu styling — it's out of the desing actually
back/forward buttons compliance — we don't break things like history and back/forward navigation
better consistency — users find Wikidot functional elements at the same places for every wiki — despite of theirs custom CSS
edit button — if you are allowed to edit — always available at top

UPDATE: if you copy and send some URL from rich interface to your friend not logged in to Wikidot — the interface would check if the user is logged in and if not — redirect them back to the basic interface. So we have full URL translation between rich and basic interfaces.

More to come in Wikidot 2

Menus created like now (as the unordered list) would render with JavaScript and not pure-CSS like it happens now. This would allow for better look and feel of them.

A great WYSIWYG editor is coming there. Clicking the edit button at the top your whole page changes into the areas you can edit. You are given an additional top-bar with some formatting functions. In general we want to have the most features we have now — accessible by mouse, which means no need to write (and learn) WikiSyntax. That would be cool.

An optional switch for WikiMasters would allow them to write the pages like now. The difference is, that we would like to change the internal storage format to based on XML for better parsing and converting. So probably we would accept some subset of XHTML with addition of some nifty Wikidot tags:

XHTML formatting tags + Wikidot-specific XML tags = WikiML

another option is that we have a totally different XML-based language to clearly distinguish between the source and the output of wiki processing.

The more I think about, the more I am for the XTML - something + something model.

Summary

This post gives you some basic idea about how Wikidot 2 will improve user interaction. As Wikidot 2 is at stage of planning and early development much can change, but what remains the same — we want to make it absolutely the best Wiki system on the planet.

And remember, probably PRO users will get the Wikidot 2 preview 3 months earlier!