Sorry, but this color scheme is unreadable. Contrast is your friend!
And I'd rather not see a bunch of "test" articles with one paragraph or so. Show me some dense, complex content, and maybe I'll grow interested (that and not having it 500 every 30 seconds).
I'm not convinced that such a precriptive statement makes sense. You could just as easily say that long-form books are about content, not presentation, yes I know of many books whose typography and presentation have a significant effect.
Perhaps Piki isn't what you think a wiki should be. Congratulations, know we know that semantic shift is alive and well.
I chose to focus on making Piki as useful as possible for smaller wikis written by individual writers. That's untypical of a wiki engine, but I think it's something worth exploring. Mass collaboration is great for some things, but the most original and polished work tends to come from individuals or small teams.
There is currently no collaboration or custom links (though a URL will turn into a link), but I plan to add these features in the future.
Not exactly. Where Piki lacks in collaboration features, I believe it's far ahead of any other wiki engine in terms of user experience, considering the user is someone who wishes to have a place to organize their own thoughts and ideas.
That is a description of a historical event, not an original work :) Like I said, mass collaboration works for some things, like recording facts. However, if you wanted to write about a fictional nuclear disaster for a video game you're developing, you'd likely be better off doing that by yourself or with a friend.
I like it! Simple and elegant. Throw in a little Markdown syntax for bolding, italics, image embeds, etc., and I think you'd be well on your way to a cool thing.
Like others, I wouldn't mind forking/contributing if you ever decided to make it open source, but I respect it all the same if you don't want to go that route. I would actually love to use this as a small part of an ongoing project where we're thinking of including a small wiki functionality (although it would need to be either open source or something that was able to run on our servers for that, not remotely hosted...)
Thank you, that's what I was going for! Piki will never use a markup language, but I plan to add drag-and-drop image embedding and right-click text stylization.
People who seem to take the most interest in this also express desire to use it locally. I'll have to figure out a way to cater to you folks.
Along with the right-click menu, I plan on creating keyboard shortcuts for text stylization (Ctrl+B for bold, etc). This would allow one to bold/unbold in the process of writing without touching their mouse, as well as to easily bold selected text.
As far as the star goes, I want to use it for beginning bulleted lists.
> One can "style" text without a "markup language". For example star text star <- bold.
But that's a markup language. The difference between * text * and <b> text </b> is a matter of syntax, not kind. Also, in most forums like this one, asterisk text asterisk gives italic text.
It becomes a "markup" language (ala markdown, etc) when the "markups" are removed and replaced by htlm codes. As you noted, in HN, when using stars they get removed and replace by some <i>...</i> stuff.
> It becomes a "markup" language (ala markdown, etc) when the "markups" are removed and replaced by htlm codes.
No. Asterisks that aren't lexical content are markup. HTML tags are also markup, just a different markup. When you replace asterisks with HTML tags, you're translating from one markup to another.
The markup cycle ends when the markup is rendered as styled text that a human recognizes as lexical content. For example, italicized text.
The thing is I don't "replace" asteriks with HTLM tags, I keep the asterisks visible.
If star text star displays star text star in bold (ie, not removing the stars, inserting </b> stuff around the whole construct), is it still a "markup language" ?
Let say I process a text file to display it in HTML and the only addition I do is say "quoted content gets italicized". Is that a "markup language", or just some "text embellishment"?
The issue I am trying to address is the learning curve with all the existing markup languages. Without going the "wysiwyg" editing way, that is.
I figured out that if the "marks" are visible in the final result, they get easy to learn.
I figured that letting people write without an account was not worth the added complexity, especially for a minimum viable product. You are free to look at any of the published wikis; the interface for writing a wiki looks almost exactly the same. I made the sign-up process as painless as possible, in case you ever change your mind.
It's not, it's speculation. But it's probably naive to assume it's possible to require information from a user (username, password is about minimal) and not turn at least somebody away.
Also, perhaps not impossible, but I've yet to see it.
I really liked that "section" -> "sub section" -> "paragraph" handling. Very unobstrusive. I am yet to study "contenteditable" but I'm glad it lets one designs such mechanisms. Kudos.
I'm happy that somebody recognized this :) It was a huge pain to mold the contenteditable element into a polished wiki editor, but I'm pretty proud of the results.
Sorry about the overload; this is my first web app and I can't afford to use anything above Heroku's free plan. I will look into the garbled text problem. :)
Any plan to make this available to others someway somehow? I've been working on a writing project that would be ideally captured in a wiki, and I've been putting off the idea of writing my own software or deeply customizing other software.
