Log in

View Full Version : documentation help requested for new mediawiki


Pages : [1] 2 3 4 5

Richard Berg
6th January 2006, 08:03
http://www.avisynth.org/mediawiki

I'd like to eventually phase out the current wiki. It's inferior in basically every way. Some features I think will be especially helpful for us:
- multiple languages of the same page
- file uploading (for images AND scripts)
- categories
- subpages (will make huge pages like the FAQ much easier to edit)
- discussion pages

This is a big undertaking, of course. If we decide to drive it to completion it will require everything from high-level doc reorganization to a logo that fits in the upper left correctly. Let me know what I can do to help. For instance, it wouldn't be too hard to write a webpage similar to http://www.richardberg.net/bin/convert.html that converts 'TaviWiki formatting to MediaWiki.

Nevertheless, there are a lot of conceptual differences in MediaWiki that don't translate directly and will influence the structure of the new site. User's Guide: http://meta.wikimedia.org/wiki/MediaWiki_User's_Guide

edit: Wilbert

We are looking for volunteers to port (copy and paste plus some small changes) the documentation from the old wiki on avisynth.org to our new mediawiki. If you want to help, please respond to this article.

Another thread with some info: ttp://forum.doom9.org/showthread.php?t=105417.

edit Wilbert:

login questions + answers:

"What does AVI stand for?" => "audio video interleaved",
"What does CODEC stand for?" => "coder decoder",
"What does CSS stand for?" => "content scrambling system",
"What does DCT stand for?" => "discrete cosine transform",

Wilbert
6th January 2006, 11:15
I think it would be nice. Too bad it's much work :( I think we just need a bunch of volunteers (say 4-6 people) who are willing to help me.

stickboy
6th January 2006, 11:47
I'm willing to help out. I had been wanting to do some reorganization anyway but never had gotten around to doing it.

BTW, is there anything different that would make it easier to keep the offline AviSynth documentation synchronized with the online wiki pages?

foxyshadis
6th January 2006, 12:32
I'd been wanting to make a 'Didee's scripts' section, now I can just make a category for them. :p

It will be so nice to have tables of contents generated automatically!

If you want I have several eye-pleasing themes. (Not mine, culled from mediawiki's site mostly and modified for mine.) Or I could throw something together matching the current documentation's style, but I was hoping that would get an update from the new site rather than vice versa. ;)

If you want my help I'll be available.

Richard Berg
6th January 2006, 18:12
BTW, is there anything different that would make it easier to keep the offline AviSynth documentation synchronized with the online wiki pages?
Maybe. Some ideas here: http://meta.wikimedia.org/wiki/Alternative_parsers

For all I know it could be done just by clever scripting of wget. (edit) The idea would be to enumerate just the article pages, append "&printable=yes" to each, then download being sure to grab necessary CSS & images.

If you want I have several eye-pleasing themes...
Sounds nice. Anywhere we can preview them?

----

Note: in addition to images, I've enabled "avs" "avsi" and "dll" as valid extensions for file uploads. I may need to restrict this permission to certain people in the future, but for now it's wide open. Speaking of which, once I configure the permissions model, Wilbert won't need to ask me every time a link in the left frame needs to be updated ;)

mg262
11th January 2006, 13:52
Wilbert,

Can I ask how you are thinking of going about things? Is the idea to move all the old content and then start editing, or to use it as source material in creating something a bit better organised? Is it okay to add things to the new Wiki, or should that wait till more framework is in place? Is it okay to start discussion page(s)?

I don't have any experience with Wikis. In principle I'd like to help, but I'm not sure how much use I'll be. I don't have a keyboard and everything is done through speech recognition; maybe it'll work fine with Wikiing, maybe not... I'd have to play with it for several hours to tell.

Wilbert
11th January 2006, 21:28
I propose we discuss about a possible reorganization first. I would like to hear the ideas that stickboy has. Perhaps other people have ideas too. After that we can divide the work and start copy-paste-and-correct-it :) Perhaps using one of Richard's parsers is easier, but i didn't look at that yet.

@mg262,
I don't have a keyboard and everything is done through speech recognition
Really? That's incredible. If you can code this way, and think you can also edit wikis this way :) Of course you can just try and see.

mg262
11th January 2006, 22:17
I'd definitely like to try. Is it okay if I try to create a page (maybe my user page) and play with it?

Thoughts...

It would be nice to have a page for each category of filters... e.g. Denoisers, Deinterlacers, Inverse Telecine Filters, Derainbowing Filters, Sharpeners. (IMO, the idea of including both scripts and filters is great... but I'll use the word filter for simplicity.) They could include a description of the nature of that kind of filter, small before/after pictures, a comprehensive list of filters of that type, and maybe a short discussion of the kind of artefacts that can arise from the filter. We could also organise filters by author, but that seems less pressing. Then a main 'Filters' page could link to the summary pages for each category?

I would say the FAQ contains too much in its current format. Better to move as much information as possible to pages with descriptive names... including the suggestion above, but also e.g. a page on YV12, a page on audio, a page on colourspaces, etc.

iradic
12th January 2006, 01:16
if you need help send me e-mail or pm, mail better

bye

foxyshadis
12th January 2006, 02:07
I'm torn on whether to use categories or not. On the one hand, you don't have to bother keeping separate pages in sync with any new stuff you add, but on the other hand, category implementation is kind of lame (3-column format only, no descriptive text). In the end lists like we have now is probably a better way to go, although if we do try to catch up and add more filters/scripts the filter categories will definitely deserve their own page.

Clouded, you can always write the page and add formatting in another mode, or have someone else do it. Twiddling is easy, it's the content-writing that's tough. (But would that mean no more weekly new filter releases? Oh, the horror! xD)

Richard, do you have any protection against spam-bots? I don't know if mediawiki has any specialized plugins enabled. Oh, and I totally missed your question on the skins, so sorry! Meta skins (http://meta.wikimedia.org/wiki/Gallery_of_user_styles#FratMan) has quite a few, that one links to my favorite (Fratman, although the 1.5 version is more "sanitized" into mediawiki's logo & colors). But there's other neat ones in there as well.

Ugh, I've got to clear my head so I can conentrate.

mg262
12th January 2006, 12:50
Could we have both categories and pages with lists? So that e.g. there would be a category Denoisers, a manually written page on Denoisers, and an automatically generated page List of Denoisers. The two pages could link to each other appropriately.

I just found an example here... Category:Cultural movements (http://en.wikipedia.org/wiki/Category:Cultural_movements) contains the text

A cultural movement is a change in the way a number of different disciplines approach their work. This embodies all art forms, the sciences, and philosophies.

The main article for this category is Cultural movements (http://en.wikipedia.org/wiki/Cultural_movements).
followed by an automatically generated list.

Edit:
foxyshadis,
other way round... I needed to relearn to code this way and for sanity's sake I needed a domain where a very short program could have a satisfying effect (small effort, big reward :)). That's why I started coding AVISynth filters in the first place. But it's counterintuitive... C++ keywords (for, class, template) and STL types and methods (vector, map, iterator, begin) are English words, and the main punctuation symbols (brackets and semicolons) occur frequently in English text. Raw HTML, containing things like "</p>" is extremely hard to write. But I can definitely manage continuous prose!

Wilbert
12th January 2006, 23:20
I copy and pasted the main page to get started. Perhaps it's better to keep some of the discussion here, so that all people can give their input?

@mg262,

I'm not convinced categories are that useful. Consider the (possible) category plugins for example. Sure it's nice that lists can be automatically generated, but i think it's better if the names are accompanied by a short description (just as in the off line documentation). I'm not completely sure, but i think that's not possible in that case.

mg262
12th January 2006, 23:33
I'm not attached to the auto generated lists at all... actually I forgot they existed until I read foxyshadis's post. What I was originally suggesting/asking for was that we have a manually written page for each kind of filter (e.g. Denoisers) rather than having one huge list as in the current Wiki.

[Looking back, I rather unfortunately wrote this: "It would be nice to have a page for each category of filters..." without realising the word category had a technical meaning... I just meant kind/type/etc.]

Wilbert
12th January 2006, 23:39
I'm not attached to the auto generated lists at all... actually I forgot they existed until I read foxyshadis's post. What I was originally suggesting/asking for was that we have a manually written page for each kind of filter (e.g. Denoisers) rather than having one huge list as in the current Wiki.
Yes, i agree. We should remove for example the external plugins from the faq (idem for the utilities), use the existing types (make/add new ones if necessary) and move them to separate pages. Just as in the offline documentation.

mg262
12th January 2006, 23:59
Sounds good! I just looked at the categories in the docs... here they are for convenience:

General info
Deinterlacing & Pulldown Removal
Spatio-Temporal Smoothers
Spatial Smoothers
Temporal Smoothers
Sharpen/Soften
Resizers
Subtitle (source)
MPEG Decoder (source)
Audio Decoder (source)
Compare video quality
Broadcast Video
Misc Plugins

I think we'll probably need quite a few more categories, especially of filters designed to remove particular artefacts (e.g. spots/scratches, rainbows). I was thinking that when I had a bit of time I might grab the list of filters on WarpEnterprises and try and classify them? Incidentally, I don't know what the difference between denoisers, smoothers and softeners is (and Sharpen/Soften contains no softeners!)... if there is one, could someone please enlighten me? (Interesting related discussion (http://videoprocessing.11.forumer.com/viewtopic.php?p=465))

Also, IMO it would be better to redesign the main page completely rather than trying to make incremental changes to this one... but I guess that even if everyone agrees with me it would make sense to leave that until we have a better idea of the overall organisation.

Is there an easy way to get a list of pages on the old site?

communist
13th January 2006, 00:15
a logo that fits in the upper left correctly.
Well its a start :)
http://www.stud.uni-goettingen.de/~s304280/D9/avisynth_mod.png

Richard Berg
13th January 2006, 00:51
Is there an easy way to get a list of pages on the old site?
There's a macro that can be used for this. Here, I'll put one up: http://www.avisynth.org/AllPages

mg262
13th January 2006, 01:02
:thanks:

Pookie
13th January 2006, 01:24
Here's how the Anime folks posted their AviSynth scripts on their Wiki.

http://www.amvwiki.org/index.php/Category:AVISynth_Scripts

http://www.amvwiki.org/index.php/Please_Teacher%21_Processing

Wilbert
13th January 2006, 23:33
I need some help :)

http://www.avisynth.org/mediawiki/wiki/Internal_filters

lists filters in different types. One such filter is Blur:

http://www.avisynth.org/mediawiki/wiki/Blur

Making the category 'Internal filters' (adding: [[Category:Internal filters]] to all filter descriptions) a category is made with all filters (sorted on alphabet):

http://www.avisynth.org/mediawiki/wiki/Category:Internal_filters

Ok, good. The problem is Sharpen and Blur are on the same page. So, I thought let's make a redirect from Sharpen to Blur:

http://www.avisynth.org/mediawiki/wiki/Sharpen

But Sharpen is still not listed in the Category page:

http://www.avisynth.org/mediawiki/wiki/Category:Internal_filters

Is this solvable?

Richard Berg
14th January 2006, 08:17
I added the [[Category]] macro to the Sharpen page. That seems to have worked. Note that you have to put it on the same line as the Redirect or it'll be deleted (see here (http://meta.wikimedia.org/wiki/Help:Redirect#Creating_a_redirect)).

Wilbert
14th January 2006, 14:52
Note that you have to put it on the same line as the Redirect or it'll be deleted.
Ah, i tried to put it on the next line, and it was deleted :) Thanks!

mg262
14th January 2006, 20:22
Wilbert,

I was looking at this post (http://forum.doom9.org/showthread.php?p=765974#post765974) and the immediate reply (http://forum.doom9.org/showthread.php?p=766000#post766000) again; can I ask whether you are planning to have a page per filter?

(FWIW, some thoughts:

+
-- Allows Wikification of AVISynth scripts and script fragments
-- More information can be presented than on a list page
-- Allows non-essential information to be removed from the list page
-- Consistency of documentation (both consistency among filters and consistency between filters and scripts)
-- Improved documentation for filters which currently largely reside on forum threads (I'm def. guilty of this myself, esp. before I had an HTML editor :o )
-- Users can clarify the documentation or augment it with e.g. known issues, examples, additional uses, alternatives.

-
-- Risk of desynchronisation/creates upkeep work
-- Many pages will be stubs at first/much content to write
-- Risk of vandalism (?)
)

Wilbert
14th January 2006, 21:06
Wilbert,

I was looking at this post and the immediate reply again; can I ask whether you are planning to have a page per filter?
We can at least do this for some filters (most used and popular filters). Of course i see also the cons (that's why i started doing it for the offline documentation), but in the end it all depends on how much time it costs and how much people are willing to help.

Btw, i wouldn't worry about vandalism. Vandalism doesn't happen much, and if it happens it's very easy to revert it back.

foxyshadis
14th January 2006, 22:29
VFR update is done, lot of stuff added and a little trashed or moved around, so have at that one. Geez, that's a messy subject, but I guess I've sort of adopted it.

Richard, does your script ignore ! before words, as well as picking up BiCap words that don't have them? I haven't looked at it.

[edit] Also, have you started any templates? I don't know a lot about them, but I'll look into it; it seems for something like this they're almost required to keep formatting mess to a minimum.

Wilbert
17th January 2006, 00:06
I edited the main page again to make some improvements.

http://www.avisynth.org/mediawiki/wiki/Main_Page

In my opinion, two things needed special attention:

1) Accessibility to newbies. I got many complains that avisynth.org is not accessibility for newbies. So i added a special section for this. It should contain at least two things: (1) learn how to make basic scripts, and (2) give a basic overview of the possibilities of AviSynth.

2) Inaccessibility of certain subjects like syntax and related stuff. Those are buried to deep and not easy to find. So i added these subjects as a special section.

I also added the section "Filters, external plugins, script functions and utilities". That speaks for itself i think :)

The development section should be a bit more structured, but that's not important now. I'm also not happy with the Tips, because you don't know what it is about without looking :)

So, what do you think of it? Is it indeed more accessible for people who are new to AviSynth?

Richard Berg
17th January 2006, 03:41
It's better, but can be better still :) The AMV page on Avisynth is very good; we might borrow some of their ideas. I like having "your first script" on the main page, for instance.

I agree the "tips" section is junk.

@foxyshadis
Richard, does your script ignore ! before words, as well as picking up BiCap words that don't have them? I haven't looked at it.
That's because I haven't written it yet ;) (I've been working on MeGUI) Do you want BiCap words without '!' to become links by default?

Also, have you started any templates?
Don't know anything about them...

@mg232
-- Risk of desynchronisation/creates upkeep work
-- Many pages will be stubs at first/much content to write
What would be great is if stickboy, fizick, tsp, vion11, & others used a wiki-page as their main website. Mediawiki's features (especially file pages) should be good enough to handle everything they're currently using their avisynth.org webspace for. Hopefully Didee, Scharfi, etc. would follow suit.

mg262
17th January 2006, 07:36
Wilbert,

That new section is looking very nice.

I really think that there is too much material on the main page. It would be nice to try and keep nearly all the material on one screen, so you can reach any second level page in one click -- using two columns like Wikipedia would help, but also a lot of material is wordy: "External plugins for AviSynth v2.5x by some of our finest authors, organized here for your downloading pleasure."

Tips and guides is as noted silly as it stands, and it's not clear where it ends and advanced topics begins. Advanced topics is a productive category -- i.e. we can keep adding to it -- so IMO it doesn't belong on the front page, because potentially it can keep growing. Random musings is also unhelpful -- editor-stuff belongs in your new category, either under utilities or more probably as a 'Editor' link. The other languages we could just treat like Wiki pedia.

@Richard Berg
Do we have easily-accessible statistics on how often the different links from the main page are used? (I.e. if something is never clicked on, it may not belong on the main page.) Please don't go to a lot of trouble to get all of these if it's tricky.

Edit: how about having the main quick links at the top, as Wikipedia and AMV Wiki do? I rigged up something to show what I mean...

http://www.avisynth.org/mediawiki/wiki/User:Clouded

(obviously the exact content will change; this is just to get an idea of the look)

Richard Berg
17th January 2006, 15:27
http://avisynth.org/awstats/cgi-bin/awstats.pl?config=avisynth.org

Wilbert
21st January 2006, 17:14
I cleaned up the main page and took Clouded suggestions into account. I think it's pretty good now, but we can always change things when needed.

I suggest we divide the workload. Perhaps Clouded can start (or continue :)) with the 'external plugins' section. foxyshadis, what do you want to do? Start with the script functions or help with the internal functions? I will start with the internal functions section, and the faq.

foxyshadis
22nd January 2006, 01:42
I checked out templates, and it seems that they could be cajoled into styling properly, but you can't just define one template that enforces a style. (And could be swapped out for another.) I was hoping for something higher level. Still, I have been experimenting in my wiki and might have some useful attempts.

As for linking, there's quite a few accidental links (plus anything in <code> is unlinked). It'd probably just be better to compare to the original to see what makes sense for inclusion.

Wilbert, I'd be glad to start cleaning up and re-adding some of the script functions. I'll have to wait until tomorrow though.

stickboy
22nd January 2006, 02:12
What would be great is if stickboy, fizick, tsp, vion11, & others used a wiki-page as their main website. Mediawiki's features (especially file pages) should be good enough to handle everything they're currently using their avisynth.org webspace for.I could give it a shot (my web page right is really basic), but what compelling reason is there to do so? Visual consistency?

Richard Berg
22nd January 2006, 05:42
Main reason: to establish that putting such things on the wiki is easy -- and if you early adopters hit pain points, fix them -- in order to encourage lots more people to do the same. Right now too much knowledge is buried in 30-page threads. I've thought about giving the most prominent script writers web accounts like yours, so their creations can be put somewhere more discoverable, but I don't think they'd really get used; writing HTML & uploading it is annoying. Wikis should make it simpler, but the old/current one is very clumsy WRT script files (no way to upload; embedding in the page instead looks like shite; no organization to speak of), so again it sees poor participation. Having it automatically version files is of course a huge plus.

mg262
22nd January 2006, 14:13
Richard,
thanks again!

@all,
Perhaps Clouded can start (or continue ) with the 'external plugins' section.
Wilbert was referring to this: it's very rough, but I figured we needed to start somewhere...

http://www.avisynth.org/mediawiki/wiki/User:Clouded/Rough_Classification

(Not just plugins... it already includes a few script fns, and would have more if there were a list of them around.) It really isn't meant as a final model, just something to discuss. Feel free to take it apart or edit it into better shape. + Please keep an eye out for misclassifications... some of these I didn't find much info on.

Edit: By the way, Wilbert, do you think the internal filters should be added to that classification as well? (It would be relatively easy as I know what they all do.)

gzarkadas
25th January 2006, 23:54
Count me in :)

Fizick
26th January 2006, 00:26
What would be great is if stickboy, fizick, tsp, vion11, & others used a wiki-page as their main website.

Who will have write access to this pages?

foxyshadis
26th January 2006, 13:54
Right now everything uploaded seems to land under Image:, which means they'll be a little more difficult to link to and use. I'd like to be able to link directly to the script from info pages, rather than its cover page, but the only way I know of is hard linking and uploading a new version will break that (since it puts it into folders named for its hash). I don't think there's a natural way to do that, but one of us could make some modifications to the wiki codease.

would Script: be a good namespace for all of that?

hanfrunz
27th January 2006, 00:12
you can use [[Media:filename.ext]] to directly link to a file!

Richard Berg
27th January 2006, 04:27
Who will have write access to this pages?
I can restrict it if you like.

I believe I also have the ability to create other aliases (besides Media) for "image" hosting by editing config files instead of hacking the PHP.

niiyan
6th February 2006, 16:25
Can I add Japanese translations to new wiki pages?

Wilbert
6th February 2006, 16:31
Can I add Japanese translations to new wiki pages?
Sure, but i think it is better that you wait for a while. We just started and things might change in the beginning. I will contact you in time.

niiyan
6th February 2006, 16:44
OK. I have already translated about half of filters' documentations to Japanese. I'll put them to new wiki.

Richard Berg
6th February 2006, 19:26
foxyshadis asked about making the URL lookups case insensitive. Having Avisource & AviSource resolve to the same page sounded good. But it turns out to be trickier to implement than it sounds. This post (http://mail.wikipedia.org/pipermail/mediawiki-l/2005-September/007129.html) summarizes the current situation.

What we really need is to pick a naming convention. For example, here's Wikipedia's:
http://en.wikipedia.org/wiki/Wikipedia:Naming_conventions#Lowercase_second_and_subsequent_words
http://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_%28capitalization%29

mg262
7th February 2006, 15:52
On the preliminary classification (link in my signature)... I've received some very helpful PM's -- thank you to those concerned. A couple of things I want to make clear:

-- You are more than welcome to make changes, corrections.
-- This isn't meant to be a final page. The aim is to get sensible categories and subcategories, so that we can create appropriate pages (e.g. a page on restoration filters, or a page on deblockers).

And a couple of questions...
-- Thoughts on how we should subclassify denoisers? Stick with the old Spatial/Temporal/Spatiotemporal scheme, or something else? [I have no strong feelings on this issue.]
-- (Esp. to Wilbert) how NPOV are we trying to keep things? For example, this:http://forum.doom9.org/showthread.php?p=759778&highlight=tdeint+mvbob#post759778 would IMO be extremely helpful to a new user.

Richard Berg
7th February 2006, 17:32
I don't have a problem with quick-n-easy lists of "best" filters. Just use careful wording like Wikipedia does.

fact: The YUY2 colorspace uses 16 bytes per pixel.
opinion: Many people feel MvBob is the best filter for pure interlaced material. fact: It's certainly one of the slowest.

We could even have a dedicated page called "Current recommendations" or similar. Then if parts are debatable, use its talk-page.

Soulhunter
7th February 2006, 18:11
Thoughts on how we should subclassify denoisers? Stick with the old Spatial/Temporal/Spatiotemporal scheme, or something else?

Spatial, Temporal, TempoSpatial and perhaps "Special" for FFT or DCT based stuff!?

Btw, I followed ya suggestion and added a dozen filters + edited some stuff... ^^


Bye

Wilbert
7th February 2006, 18:18
I don't have a problem with quick-n-easy lists of "best" filters. Just use careful wording like Wikipedia does.

fact: The YUY2 colorspace uses 16 bytes per pixel.
opinion: Many people feel MvBob is the best filter for pure interlaced material. fact: It's certainly one of the slowest.

We could even have a dedicated page called "Current recommendations" or similar. Then if parts are debatable, use its talk-page.
I don't like that. It's very subjective and difficult to keep up to date. Not to mention that it depends on the source sometimes (think about denoisers). Imo, it's not up to us to rank the filters. Of course you can list advantages, disadvantages and bugs. Then people can make up their own mind.

Richard Berg
7th February 2006, 19:16
Ok, no rankings. We can definitely put up objective data, though. Things like speed, compressability gain/loss (for denoisers/sharpeners), features. On a similar note, feel free to upload lots of samples: "torture test" clips, filter comparisons, whatever. I bargained for a lot more space & bandwidth after the site went down in Dec, may as well use it :D

foxyshadis
7th February 2006, 19:49
Oooh, samples. Definitely put Didée's B5 torture test on there. :p It'd be very interesting to have screenshots of what denoisers do to a few "standard" mildly noisy and very noisy clips, later on.

As for names, I guess the only way is hack the code to insert a lot of strtolower()s, cross your fingers, and hope for the best, so.... not exactly a good plan. I guess that since every filter already has a known case (Pascal case being the most common by far), we should use that. Maybe even force Pascal case for all-lower-case ones. The old wiki generally Pascal-cased almost everything except a few wiki-style links, and I kind of like that, but with spaces so things look more like "proper" titles. But that's just my opinion.

ie, "Variable Frame Rate Video" instead of "VariableFrameRateVideo" or "Variable frame rate video". (Though I'm also going to link "VFR" to that one... ;))

mg262
7th February 2006, 20:20
Grrr... lost my reply. Briefly,

@Soulhunter: thank you for the suggestions, the changes and for pointing out the issue about naming conventions!

@Wilbert: should I include internal filters on the list?

@all: I'm worried that a list like this (however presented)...

Area
BlendBob
DGBob
FieldDeinterlace
GreedyHMA
InterpolationBob
KernelDeint
LeakKernelDeint
MVBob
SmoothDeinterlace
TDeint
TomsMoComp
(+ more when finished)

... will overwhelm a new user. Any thoughts on ways to alleviate this?

Also, I can think of three naming conventions for "restoration filter" subcategories:

1. Anti-aliasing, Rainbow and Dot crawl removal, Chroma correction, Deblocking, Deinterlacing, etc
2. Anti-aliasers, Rainbow and Dot crawl removers, Chroma correcters, Deblockers, Deinterlacers, etc
3. Aliasing, Rainbows & Dot crawl, Chroma errors, Blocks, interlacing

3. seems inappropriate (to me) but I have no preference between 1. and 2. ... or perhaps someone can think of something better?