New frontiers for tiddlyweb/tiddlywiki
Peter Neumark
Ben Gillies
On Wed, Jul 6, 2011 at 4:11 PM, Peter Neumark <neumar...@gmail.com> wrote:
> Hi all!
> I think it would be interesting to start a discussion about mid- to
> long-term directions of potential growth for the tiddly universe.
Cool. I've been doing a lot of thinking about this myself, though
concentrating on the set of libraries and JavaScript that could be
used to build the next TiddlyWiki (among potentially other things)
instead of TiddlyWiki itself. See
http://bengillies.tiddlyspace.com/#TiddlyLib%20%5B%5BTiddlyLib%20Wikitext%5D%5D%20%5B%5BTiddlyLib%20Motivations%5D%5D
for a summary of my thoughts.
> + I love the "everything is a tiddler" approach: code and data are not
> intrinsically separated.
I like the "everything is a tiddler" thing, though I'd add a caveat
that I believe code tiddlers and data tiddlers should not be mixed up
(i.e. there should not exist hybrid code-and-data-in-one tiddlers). As
That gets really confusing quite quickly.
> + The shadow tiddler mechanism of attributing special meaning to certain
> tiddlers like PageTemplate (and hardcoding a backup copy of their contents)
> is very intuitive. Magic tags like systemConfig also make sense.
Going with the theory that everything is a tiddler, I'd agree that
certain tiddlers should hold things like JavaScript, or templates. In
the interests of keeping TiddlyWiki up to date with modern web
practices though, I'd personally be more interested in separating that
sort of content out based on Content type (e.g. a tiddler of type
JavaScript becomes a plugin, etc) rather than magic tags, which
interfere with the tags on "data tiddlers" and serve to confuse
things.
> Tiddlywiki has a long history. The days when it was primarily a wiki are
> long gone. Today it is more of an application development platform.
I'd agree with that. One of the core ideas behind my thinking has been
that it ("it" being whatever set of libraries we end up with) should
be really easy to integrate with other JavaScript libraries/frameworks
that already exist (e.g. Backbone). This obviously means that you'd be
able to pick and choose which modules you want (e.g. just a wikitext
parser, or just something that syncs with the server backend) and
leave out any that you don't. My hope with this is that it would
become easier for people to use TiddlyLib to develop applications in
the way that they already know.
> - The TiddlyWiki markup language is not formally defined. It is nontrivial
> to determine if the current execution environment has every plugin loaded
> which is necessary to render a tiddler to HTML. The TiddlyWiki markup
> language is competing with lots of other wiki markups and non-wiki markup
> languages like HTML itself (favored by tiddlywiki 5 if I am not mistaken).
Indeed, I've been thinking about how we could fix this too, and I've
come to the conclusion that supporting macros/inline CSS/HTML
fragments is a bad idea and that what we should be doing instead is
supporting more than 1 form of rendering (e.g. wikitext _and_ HTML
_and_ svg etc). Macros would then become no more than transclusions,
where the thing you're transcluding would be an HTML tiddler that has
some script tags (see
http://bengillies.tiddlyspace.com/#%5B%5BTiddlyLib%20Wikitext%5D%5D
for a more detailed explanation).
> - Data should be stored as JSON where possible (I know it hasn't been done
> this way for historical reasons). Example: DefaultTiddlers.
I'd argue that data should be stored in whatever format is most
appropriate. DefaultTiddlers for example, would be stored in the HTML
page itself, so that they are loaded up when the page is loaded and do
not have to be added via JavaScript.
> - The fields of a tiddler have no "official" semantics. This buys
> flexibility at the cost of code reuse (eg: I need to understand why a given
> plugin sets a certain field, what range values it can have, etc.). Even
> experienced tiddlyweb users can be confused by what the 'tiddler.source'
> field is for, who set it, and why. This is compounded by the fact that as
> plugins evolve, the set of fields they use changes. Ideally it should be
> obvious from the name of a field which plugin uses it.
I've not really thoughts about fields much. I don't really have a
problem with them if I'm honest, as to a large extent, things like
tiddler.source are fields because they're not intended to be seen.
> Could (most) fields
> themselves be tiddlers, bringing the metadata on the same level as the code
> and data?
Given that most tiddler fields are about the tiddler they're linked to
specifically, I'm not sure it really makes sense to separate them.
> - Bags currently serve a dual purpose: in addition to acting as namespaces
> for tiddlers, they also define access control policy for the tiddlers
> contained within. In practice, this makes it nontrivial to "give" another
> user a tiddler or to read a single tiddler from another user's bag without
> following his space (importing all of his tiddlers). It also makes changing
> permissions costly, since the fully qualified name of the tiddler also
> changes.
As I understand it, this was done as permissions are typically a
tricky thing to get right and that, by keeping them really simple,
they're a lot easier to understand and a lot harder to mess up.
> - Recipes add complexity by introducing a new mini-language. They can also
> be a bottleneck because of their sequential execution model. Finally,
> recipes are difficult to use if I want to override some tiddlers from
> previous bags but not all of them.
Did you have anything in mind? I'd just add that the "space" concept
from TiddlySpace was added to give recipes a default setting that's
easily understandable (maybe default setting is the wrong way of
describing it? Abstraction maybe?).
> - The user interface is fairly closely coupled with the remaining code in
> tiddlywiki (for historical reasons). This makes it difficult to do things
> like port the widgets used by TW to jQuery UI or YUI.
Yes. See my comments about wikitext, app platform and DefaultTiddlers.
> - The sematics of magic tags and shadow tiddlers and not well documented. It
> is difficult to extend the system with newer shadow tiddlers or additional
> "magic" tags.
I'd like to move to a system where we define stuff based on how it's
used, rather than magic tags. For example, the contents of a script
tag would become a JavaScript tiddler. Which would remove the need for
magic tags.
> Joe has been contemplating how coding "should be". His wish list:
Can you define what you mean by coding? For example core development,
vertical app development, collaborating on a wiki, etc.
> 2. People who are interested in the same thing (eg. two people who both need
> a PNG parser) should be able to find each other so they can collaborate on
> the code. Not only would this provide quicker results and strengthen the
> community, it would also help prevent fragmentation (how many logging
> libraries are there for java? 14?).
I believe that's one of the ideas behind the following mechanism in
TiddlySpace (i.e. if I write a tiddler called "PNG Parser" I can see
who else has written about a "PNG Parser" and get in contact with
them).
> When Joe discovered tiddlyspace, he felt like he had a pretty good starting
> point to create his ideal development environment for erlang. Since all of
> his ideas apply equally well to any programming language, tiddlyspace could
> implement these for javascript.
I'd be interested in hearing these ideas...
> 4. Several people could edit the same tiddler simultaneously (google docs
> style).
A git style merging and diffing mechanism you mean? While that would
be cool, I'll just point out the differences between Google Docs and
TiddlyWiki. Tiddlers generally are quite small so: if tiddlers are
small enough and well defined enough, then would it not be the case
that we'd only have to deal with multiple people editing the same
space/wiki, and not multiple people editing the same tiddler?
> 5. The people editing/viewing a wiki could talk to each other directly
> through a chat window. This could even be generalized to "the people
> accessing the same cluster of tiddlers", as the goal is to connect people
> with similar interests.
Sure, but there are a number of real time chat solutions already out
there. I'd worry about us making something too similar to Google Wave
(i.e. horrific and complicated) if we did that. We want to facilitate
better communication sure, but I'm not sure I'd favour a real time
chat component.
> 6. Comments should be visible when they are made, not upon page reload. You
> should be able to comment a section of a tiddler, not just the whole thing
> (eg. a line of code in a plugin tiddler).
Is that not two different things? The first part: I agree. The second
part: I'm not sure I follow.
> 7. Metadata changes should be visible to other viewers when they are made
Yes. All changes should update in (pretty much) real time for anyone
whose viewing that wiki.
Thanks for starting this thread, I'd been meaning to start it myself
and am interested in other people's thoughts.
Ben
PMario
> I think it would be interesting to start a discussion about mid- to
> long-term directions of potential growth for the tiddly universe.
> Day-to-day most of us are concerned about the nitty-gritty engineering
> details. While these issues are important and often interesting,
> sometimes it makes sense to talk about the bigger picture so people with
> aligned interests can find each other and develop common ideas, conventions
> and code.
his approach quite interesting, but the result of any refactoring IMO
should be something, that can be used by endusers as well as
developers. There are plenty of dev-only tools out there.
> + I love the "everything is a tiddler" approach: code and data are not
> intrinsically separated.
> + The extendability of both tiddlywiki and tiddlyweb is very impressive and
> no doubt contributed to the number of users it has today.
> + The ability to include or follow other spaces in tiddlyspace is supercool.
> I love the fact that I can include preso and instantly make presentations.
> + The shadow tiddler mechanism of attributing special meaning to certain
> tiddlers like PageTemplate (and hardcoding a backup copy of their contents)
> is very intuitive. Magic tags like systemConfig also make sense.
When I saw a TW plugin the first time I thought of literate
programming [2]. I thought, that's nice, if the core is made the same
way. The problem is, it isn't.
> - Data should be stored as JSON where possible (I know it hasn't been done
> this way for historical reasons). Example: DefaultTiddlers.
http://pmario.tiddlyspace.com/About.json
I still like the TW data store, even if it isn't up to date. But if
you use the right browser, a "file TW" is totally self contained.
Without the need of HTML5 data stores, that can't be sent by mail.
> - The fields of a tiddler have no "official" semantics. This buys
> flexibility at the cost of code reuse (eg: I need to understand why a given
> plugin sets a certain field, what range values it can have, etc.). Even
> experienced tiddlyweb users can be confused by what the 'tiddler.source'
> field is for, who set it, and why. This is compounded by the fact that as
> plugins evolve, the set of fields they use changes. Ideally it should be
> obvious from the name of a field which plugin uses it. Could (most) fields
> themselves be tiddlers, bringing the metadata on the same level as the code
> and data?
FreeStyle [3] project. Where tiddlers, that are used as a
configuration, also conatin documentation [5]. The programmatically
usefull part, are the sections "Code" and "List" at the bottom of the
tiddler. The rest is documentation.
The problem is, that you have to write your own parsers for "Code" and
"List".
And you have to write a lot more documentation [6], only to discribe,
the way you are thinking.
The good thing with TW is. It is possible to do it that way :)
> - The user interface is fairly closely coupled with the remaining code in
> tiddlywiki (for historical reasons). This makes it difficult to do things
> like port the widgets used by TW to jQuery UI or YUI.
direction?
> - The sematics of magic tags and shadow tiddlers and not well documented. It
> is difficult to extend the system with newer shadow tiddlers or additional
> "magic" tags.
> I have been fortunate enough to participate in a conversation with Chris
> Dent and Joe Armstrong of Erlang fame.
It would be interesting to get some more info about this.
> 3. Code should be inseparable from documentation. Not the kind of
> documentation you write for your boss once all's set and done, but the
> actual research that goes into writing the code. This blogs, api references,
> pdf articles that provide the necessary input for your work. Comments by
> others should be visible in the code see others can follow the discussion
> that led to the current implementation.
> When Joe discovered tiddlyspace, he felt like he had a pretty good starting
> point to create his ideal development environment for erlang. Since all of
> his ideas apply equally well to any programming language, tiddlyspace could
> implement these for javascript.
> I have been thinking a lot about the best way to create collaborative
> software - something like google docs - without the backing google has.
> 4. Several people could edit the same tiddler simultaneously (google docs
> style).
> 5. The people editing/viewing a wiki could talk to each other directly
> through a chat window. This could even be generalized to "the people
> accessing the same cluster of tiddlers", as the goal is to connect people
> with similar interests.
implemented the "typewith.me" service into every tiddler at his
semantic [7] page. You need to click the most left "speak buble" at
the tiddlers toolbar to see it.
The problem here is, that you have to rely on a third party services.
But since the SW is open source it could be adjusted to our needs.
> 6. Comments should be visible when they are made, not upon page reload. ...
I think CDent is working on this for tiddlers.
> ... You
> (eg. a line of code in a plugin tiddler).
bloated.
> 7. Metadata changes should be visible to other viewers when they are made
> (just like changes to the contents of a tiddler).
my 2 €ents
Mario
[1] http://pmario.tiddlyspace.com/#%5B%5BTiddlyLib%20Wikitext%5D%5D%20TiddlyLib%20%5B%5BTiddlyLib%20Motivations%5D%5D
[2] http://en.wikipedia.org/wiki/Literate_programming
[3] http://freestyle.tiddlyspace.com/
[4] http://freestyle.tiddlyspace.com/#%5B%5BThe%20tutorial%5D%5D
[5] http://freestyle-nostalgia.tiddlyspace.com/#NostalgiaThemeProject
[6] http://freestyle-tutorial.tiddlyspace.com/
[7] http://semantic.tiddlyspace.com/
Joe Armstrong
At the moment I'm just reimplementing the tiddlywiki in my favorite language
just as a programing exercise, but several things spring to mind.
1) Tiddlers are should be "more declarative"
I want a shadow tiddler called PageColor whose values is "red"
and *not* a css style sheet
2) I want to gather the globals in a small number of places
ie I don't want a tiddlers called PageColor and SiteTitle scattered
in the tiddlerspace. I want TiddlerConfig to have all the configuration data
and in JSON
ie
TiddlerConfig
pageColor = "red";
siteTitle = "My web site"
...
IFYSWIM
3) I want all the undocumented things to be documented
A block start is the character sequence "{{{\n" on a line by itself
and what the heck are all these undocumented things like /*{{{*/
((actually they might be documented -- if only I could find the
documentation)
4) I want to send messages to tiddlers
5) I want simple js functions render(TiddlerText) => HTML should be
in one plave with no global leakage etc.
6) I want the design to scale to planetry scale tiddler spaces. The Erlang
folks have make planetry scale key-value stores (Riak) and replicated
kepp-all-the-old-value stores (couchDB)
7) I want all the information the web as tiddlers
(we need to do massive content injection - ie split every HTNL document
at the h1 tags and inject into the tiddly space)
Why? to reduce the granularity of content. Small grains are easy to
edit, revise, send in messages.
8) I want full history. All tiddlers should have a parent so we can trace ideas
So far I'm tyring to implement what I consider to be the "essence of the
tiddlyweb/tiddlywiki" but I don't want to throw away the baby with the
bathwater.
The tiddlywiki/tiddlyweb is the best way I've every seen for
organising information
we need to build upon this goodness in a way that levers what the tiddlyfolk
have learnt about organising information and the erlang folks know about
scaling up systems.
If I could highlight one problem it's (In my mind) clear spcs. of how
things should behave - wide-scape adoption, means open-standards, RFCs
multiple implementations in different programming languages etc.
Time for bed now - the Internet may never sleep but I have to.
Cheers
/Joe Armstrong
> --
> You received this message because you are subscribed to the Google Groups "TiddlyWeb" group.
> To post to this group, send email to tidd...@googlegroups.com.
> To unsubscribe from this group, send email to tiddlyweb+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tiddlyweb?hl=en.
>
>
PMario
> I want a shadow tiddler called PageColor whose values is "red"
> and *not* a css style sheet
theme changing quite easy.
Background: #fff
Foreground: #000
...
(you could use white and black too)
evaluated by the core and reverenced in StyleSheetColors [3] with:
body {
background:[[ColorPalette::Background]];
color:[[ColorPalette::Foreground]];
}
reverenced within a tiddler using the <<tiddler>> macro with
<<tiddler "ColorPalette::Background">>
programmatically accessed with a core function:
store.getTiddlerSlice() [4]
and
store.getTiddlerSlices() [5] returns an object with all of them :)
=====
There are Tiddler Sections too. Sections are defined by headings.
eg:
!Section 1
some text
!Section 2
some more text
<<tiddler "tiddlerName##Section 1">> returns "some text"
store.getTiddlerText() [7]
.....
> 2) I want to gather the globals in a small number of places
> ie I don't want a tiddlers called PageColor and SiteTitle scattered
> in the tiddlerspace. I want TiddlerConfig to have all the configuration data
> and in JSON
> ie
> TiddlerConfig
> pageColor = "red";
> siteTitle = "My web site"
> ...
> IFYSWIM
> 3) I want all the undocumented things to be documented
> A block start is the character sequence "{{{\n" on a line by itself
> and what the heck are all these undocumented things like /*{{{*/
> ((actually they might be documented -- if only I could find the
> documentation)
[1] http://pmario.tiddlyspace.com/#formatting
hope this helps
-m
[2] http://tiddlywiki.com/#ColorPalette
[3] http://tiddlywiki.com/#StyleSheetColors
[4] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/TiddlyWiki.js#L196
[5] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/TiddlyWiki.js#L207
[6] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/TiddlyWiki.js#L91
chris...@gmail.com
> I have been fortunate enough to participate in a conversation with Chris
> Dent and Joe Armstrong of Erlang fame.
> Joe has been contemplating how coding "should be". His wish list:
One thing I forgot to mention in that conversation (because we
didn't actually address the coding goals much) is a project that I
worked serveral years ago:
http://www.cs.indiana.edu/~rawlins/symphony/symphony.html
which appears to have some similarities to the spirit of what you
and Joe are talking about: peer to peer, real time, dynamic
evolution of coding modules on the open network. My participation in
the project was getting the local "pools" in KnownSpace working, we
didn't make it to distributed pools, but I should be surprised if
they've made it further since then. At the back of my mind I have an
evolution of TiddlyWeb in mind which is pool driven, but didn't go
that way in the first pass as it did not fit with the goals of
simplicity, transparency and interoperability with existing
TiddlyWiki stuff.
> One of the best ways to collaborate is to work in a wiki. Tiddlywiki could
> facilitate collaboration even more if:
These are all great ideas, but some it doesn't feel to me like they
need to be a part of TiddlyWiki or TiddlyWeb. The web at large provides
solutions for simultaneous editing, real time chat, etc.
There's no need, in my mind, for us to build that functionality into
a tool. To put it in another way:
In another thread we've been talking about how it is hard to use
tiddlywiki for other purposes because its code is not modular. It
would be better if it enabled the behaviors it allows by composition
of disparate parts.
Yet here in this thread we seem to be talking about adding more to
tiddly* when in fact we should be working out ways to compose simple
things that already exist.
Beyond the simple goal of getting a project (make a good server side
for tidldywiki with good http principles) that I was excited to do
done in a good way I also had a few other goals with TiddlyWeb:
* Inject the principles of the web into the tiddly universe
* Inject the principles of unix into the tiddly universe
This means that tools should be simple and as single minded as
possible. Should compose via pipelines. Should make use of
persistent URIs and diverse representations to allow them to travel
easily between tools, by reference, not copy.
Thus: If we're going to talk about something like on the fly in
browser chat[1] between people looking at the same tiddler, then what
we need is twofold:
* an orthogonal chat service that is topic oriented and has a web
interface (these things already exist as what amount to libraries)
* a notification system client-side to tell the service that an edit
has started
That second is a critical thing to think about. When you start
editing a tiddler, the web server doesn't know. This is a good thing. It
is why the web scales, it is what has made HTTP work and be useful
to all kinds of people with differing technical abilities. The
server is ignorant of the client until (and only while) the client
makes a request. Changing that dynamic raises complexity by orders
of magnitude, so making the change should not be taken lightly.
In any case, if a tiddler opens for edit, the chat server needs to be
notified, and then off you go.
The tiddlyweb server can (and should) be left out of the
interaction. It provides tiddlers.
More on that last point later in the thread.
[1] I'm not convinced there is any value of in browser chat. Why not just
use jabber, irc, aim, etc in a tool dedicated to the task?
--
Chris Dent http://burningchrome.com/
[...]
chris...@gmail.com
> Going with the theory that everything is a tiddler, I'd agree that
> certain tiddlers should hold things like JavaScript, or templates. In
> the interests of keeping TiddlyWiki up to date with modern web
> practices though, I'd personally be more interested in separating that
> sort of content out based on Content type (e.g. a tiddler of type
> JavaScript becomes a plugin, etc) rather than magic tags, which
> interfere with the tags on "data tiddlers" and serve to confuse
> things.
The everything is a tiddler and tiddlers have type is the part of
the work you're doing now that most excites me.
I envision TiddlyWeb + Tiddlers + Clients as an abstraction
modelling the web, not just the tiddly-web. It makes concepts like
links, attributes and type a little more accessible and a little
easier to manage and manipulate (in some cases).
The libraries that get created in this process should be able to
treat anything that has a URI as a tiddler.
chris...@gmail.com
>> 6. Comments should be visible when they are made, not upon page reload. ...
> I think CDent is working on this for tiddlers.
If I am or was, it has slipped through the cracks. I'm not actively
working on comment related stuff at the moment.
chris...@gmail.com
a) http://en.wikipedia.org/wiki/Posting_style#Trimming_and_reformatting
b) responses within
> 2) I want to gather the globals in a small number of places
> ie I don't want a tiddlers called PageColor and SiteTitle scattered
> in the tiddlerspace. I want TiddlerConfig to have all the configuration data
> and in JSON
While this helps in some aspects it hinders in others: It becomes
harder to override (via recipe cascades and similar mechanisms) at a
granular level. This is a constant conflict with these sorts of
things: who and what do we want to optimize for and at what level of
composition?
> If I could highlight one problem it's (In my mind) clear spcs. of how
> things should behave - wide-scape adoption, means open-standards, RFCs
> multiple implementations in different programming languages etc.
I think this is partly a cultural thing. I agree that it would be
very valuable, the whys and hows of it not having happened yet would
make for a good study of open source community culture.
PMario
> On Wed, 6 Jul 2011, PMario wrote:
> >> 6. Comments should be visible when they are made, not upon page reload. ...
> > I think CDent is working on this for tiddlers.
>
> If I am or was, it has slipped through the cracks. I'm not actively
> working on comment related stuff at the moment.
anymore?
chris...@gmail.com
> You are not working on the pubsub, webfinger, push notification thingy
> anymore?
I am, but there's nothing in there (as yet) for intra-tiddlyspace
comment handling.
Bill Seitz
PMario
> I'm a bit concerned that this is all development in the vector of defining
> Tiddly* as a development framework, rather than focusing on features that
> would make it more adoptable by end-users for a specific purpose...
I don't know, if Peter is a developer but all the others are. May be
that's the reason why the posts are (a little bit :) dev related.
I personally would like to here, how others would want to push the
Tiddly* limits, from a users point of view.
Your turn :)
-m
Ben Gillies
> On 7 Jul., 17:17, Bill Seitz <flux...@gmail.com> wrote:
>> I'm a bit concerned that this is all development in the vector of defining
>> Tiddly* as a development framework, rather than focusing on features that
>> would make it more adoptable by end-users for a specific purpose...
> Hi Bill,
> I don't know, if Peter is a developer but all the others are. May be
> that's the reason why the posts are (a little bit :) dev related.
Indeed, I'm speaking more about the internal workings of the code
that, when put together, makes up TiddlyWiki, rather than TiddlyWiki
(as experienced by users) itself. I wouldn't worry about things
becoming too dev oriented, as my hope is that this work will allow us
to create something that, if anything, is easier for non-dev users to
customise and use than at present.
Ben
Peter Neumark
Joe Armstrong
Absolutely - a casual user should never have to mess with css regexps js etc.
to make a simple customisation.
(ranting mode on:
To do *anything* fancy on the web you need a passing familiarity with:
- html
- css
- javascript
- a database (say mySQL)
- a server language (say PHP)
- a web server (say Apache)
This is an appalling bad state of affairs - a complete **** up.
There should be *one* language for this not six
One way to hide this nightmarish mess of accidental complexity
is to make a large number of mini domain specific language
end)
A tiddler is a DSL. The tiddler SiteTitle is a DSL
and the DSL (for SiteTitle) is so simple anybody could learn it
We could think of a large part of the tiddly wiki as being many small
DSLs
PageColor => A DSL for setting the page color
etc.
Beautifully simple
/Joe
>
>
> Ben
Bill Seitz
* packaging of TiddlySpace communicating at university people
PMario
> To make my point:
> The tiddlywiki GUI code is no longer making application developers' lives
> easier.
easier, it should give an enduser the possibility to easily
configure / change his environment. And keep this configuration inside
the TW.
eg: If a user doesn't like the order of his toolbar
|ViewToolbar| +editTiddler closeTiddler permalink
eg: the closeTiddler should be the most right positon
I tell him/her just change the ToolbarCommands tiddler:
|ViewToolbar| +editTiddler permalink closeTiddler
And if you mess up your toolbar, just delete it, then the default
configuration takes over again.
Now try to do the same with a SinglePageApp (SPA), where the page
layout is HTML hardcoded.
> In fact, if you let a designer decide what the UI looks like, you're going
> to have to get rid of most of the tiddlywiki UI (eg. sidebar menu,
> ToolbarCommands, etc).
and make it smaller and nestable.
-m
Ben Gillies
> On 8 Jul., 14:02, Peter Neumark <neumark.pe...@gmail.com> wrote:
>> To make my point:
>> The tiddlywiki GUI code is no longer making application developers' lives
>> easier.
> IMO the tiddlywiki GUI shouldn't make an application developoers live
> easier, it should give an enduser the possibility to easily
> configure / change his environment. And keep this configuration inside
> the TW.
I believe that both viewpoints are important. On the one hand, end
users need to be able to customise things easily (something I've said
before) but, on the other hand, if it's too awkward for people
developing new apps, then they simply won't use it.
I believe we can suitably accommodate both sets of users. It's this
goal that I'm referring to when I say, "it should be really easy to
not use".
> eg: If a user doesn't like the order of his toolbar
> |ViewToolbar| +editTiddler closeTiddler permalink
>
> eg: the closeTiddler should be the most right positon
>
> I tell him/her just change the ToolbarCommands tiddler:
> |ViewToolbar| +editTiddler permalink closeTiddler
>
> And if you mess up your toolbar, just delete it, then the default
> configuration takes over again.
By making everything a tiddler, giving tiddlers a type and keeping the
overall structure modular, one could imagine creating a Toolbar DSL
module that transforms tiddlers with an
application/TiddlyWiki.template type (or whatever) into HTML. To the
end user, they'd still just change some text or delete a tiddler using
the normal syntax. An app developer, used to JavaScript and HTML,
could just remove the Toolbar DSL tiddler and do their own thing
unencumbered by the extra syntax/code.
> Now try to do the same with a SinglePageApp (SPA), where the page
> layout is HTML hardcoded.
I hope that makes some sort of sense and gives a hint as to how both
sets of users can be catered for.
>
>> In fact, if you let a designer decide what the UI looks like, you're going
>> to have to get rid of most of the tiddlywiki UI (eg. sidebar menu,
>> ToolbarCommands, etc).
> I am not sure about this. You need to get rid of most of the TW CSS
> and make it smaller and nestable.
A designer, if they want, would then just be able to remove the
template and CSS and start with a blank canvas confident that all the
functionality they want is still there under the covers.
Ben
PMario
> My perspective may different from the rest of you, and may not be
> appropriate to this thread...
>
> http://billseitz.tiddlyspace.com/
-m
chris...@gmail.com
> To do *anything* fancy on the web you need a passing familiarity with:
>
> - html
> - css
> - javascript
> - a database (say mySQL)
> - a server language (say PHP)
> - a web server (say Apache)
>
> This is an appalling bad state of affairs - a complete **** up.
Are you sure about that? There are more people involved in the
creation of content, applications, fun, games, and extremely useful
stuff now than there ever has been before. HTML, CSS, JavaScript etc
may be a complete mess, but it has penetrated where nothing has
before.
It all sucks, outrageously, but it sucks less than anything else.
So I agree with you, but I guess I'm less disappointed about it.
chris...@gmail.com
> The tiddlywiki GUI code is no longer making application developers' lives
> easier.
This is partially true but it depends a lot on one's point of entry.
Some people come to tiddlywiki and think it is a fabulous
development environment, they are finally able to do things they
always wanted to do.
Other people find it a mess of spaghetti and hard to work with.
Others find it out of date and would prefer to experiment with something
newer to maintain progress on their educational or career goals.
So it isn't necessarily about making lives easier, it might be about
styles of expression.
But the end result is the same: a significant portion of the
experimentation going on around tiddlyspace is around assembling
tiddlers to do interesting things with JavaScript and HTML, but not
the oringal TiddlyWiki code.
> Keeping it simple as Chris Dent mentioned is central to tiddlyweb's design.
> Following this principle, I recommend we modularize tiddly* in such a way
> that the user-facing stuff is an optional bit of functionality (perhaps
> enclosed in a tiddlyspace) which we may choose to include, extend or
> rewrite entirely within our own tiddlyapps.
This is in alignment with my own thoughts, and those I've heard from
at least Ben, FND and Jon.
Tobias Beer
> On Fri, 8 Jul 2011, Peter Neumark wrote:
> > The tiddlywiki GUI code is no longer making application developers' lives
> > easier.
> styles of expression.
a name of TiddlyBase or such - that comes with (most of) the core's
logic but only a most rudimentary template... one that resets all css
to a blank cross-browser standard ...leaving it up to anyone designer
to fill the gap of actually defining the presentation layer, meaning
ALL layout and looks. No predefined SiteTitles, no mainmenu's, no
sidebars, no nothing, not even (or especially not) a ColorPalette...
just a story and all the core functions and logic that make tw tick
and that's it.
In other words, it would be nice to have a raw block of tiddly-ore and
be able to melt and weld it into whatever fits best. This were of
course not a workflow for your everyday user... but one for those guys
who want to work off of a much cleaner base than TW provides today.
Cheers, Tobias.
Tobias Beer
This kind of modularization and boiling TW down to an essential core
with perhaps more extensible hooks should imho lead to having
(backend) components loaded on demand, like the - at least in my world
- hardly ever used backstage area or something like Joe's messaging
component, or a TiddlySpace client package, etc... all of this either
via includes onload or perhaps bookmarklet-style-lazy loading.
It would make it simpler to bake a TiddlyWiki instance for which - for
perhaps more than one reason - the single file paradigm is but one way
to look at things and perhaps no longer the most vital one in a world
where simple to use and manage cloud based, thus serverside
interaction models seem to rule the landscape.
Cheers, Tobias.
Peter Neumark
PMario
> Well spoken, Tobias.
> I wholeheartedly agree with all you have said in the last two mails.
think.
Lately a lot of energy went into a "semi public" and from my point of
view "complicated", "import, export" file TW using Dropbox [1] for
collaboration. This topic has >40 responses, which is quite a lot on
the TW group. There are posts from well known members, but more
importantly there are several new names (At least for me).
So there must be a need of a more "private" collaboration environment.
The cloud (TiddlySpace), doesn't seem to satisfy this need. Even if
you can define every tiddler private.
IMO everything that was discussed at the "Collaboration using Dropbox
- looking for investigators" thread [1], can be solved with
TiddlySpace. I personally wouldn't want to use it as a file sharing
tool but it would be possible (at the moment).
May be, it is a matter of trust or a lack thereof.
May be, there isn't enough information about how to use TS for
collaboration. The ambit space beautifully demonstrates some
possibilities..
May be, we just try to satisfy our "huntung and collecting" need, and
have our data save and secure close to us. At least for me this could
be a reason :).
just 2 more €ents
-m
[1] http://groups.google.com/group/tiddlywiki/browse_thread/thread/56449fa87aa8d4cf
Tobias Beer
> Lately a lot of energy went into a "semi public" and from my point of
> view "complicated", "import, export" file TW using Dropbox [1] for
> collaboration. This topic has >40 responses, which is quite a lot on
> the TW group. There are posts from well known members, but more
> importantly there are several new names (At least for me).
dropbox scenario but a serverside, hosted environment for content
development and authoring... probably a TiddlyWeb rather than a
TiddlySpace, perhaps resulting in a more cms type application or
development environment... but above all, more granular and more
modular... no longer based on the single file paradigm... but rather
making full use of things that still only work under the hood and well
tamed in a universe of TiddlySpaces ...like bags, roles and recipes.
Cheers, Tobias.