Administration
- General Configuration page: I'd like to be able to add individuals to Authors or Doc-Admins; appears I can only add groups
- Version Management:
- I have activated a version but I can't tell from this which version was activated or published:
Adding a Page
- Schedule New Page seems a very button label. Unless you are anticipating wait times above and beyond seconds Create + a spinner should be enough eh?
- Why is it necessary to have the key appear in the title? Why not put it right after version in the version bar you created.
- Often times in long pages, we want the help to go to a secondary heading in the page. This would mean you would need to support PAGEKEY:#anchor type constructions for Help systems. Will that work with this?
- Edit Page:
- The term Schedule Modification is unfortunate. It implies to me as a user (and as an evaluator) that a simple creation operation can actually be very long. What is wrong with the commit language people are already familiar with from change control systems? If you anticipate that these operations can be very long, I assuming you are looking at the performance with very large systems. If it can run into minutes or hours there should be some kind of screen I can go to see pending operations.
- Recently updated why does it show .Initial-Test
- I think this is a Major issue. You are requiring authors to specify a new key across versions. IOW, if I have How to Restart JIRA with a Page key of 101 in Version 1.0 I can't have a Version 2.0 page called How to Restart JIRA with the same page key. This means each time I rev a documentation set I have to respecify the keys. For a space with a huge number of help files, this is pretty unworkable. I've seen systems with pages and pages of keys. Moreover these keys would need to be changed in the software and the help. Wow. Very cumbersome.
Brings up another issue, is there a way to generate a list of pages and their Keys? Better to gen it as a text file which could be pulled into a mapping file in some software systems.
General Commentary
The current design is still forcing the author to very much be aware of which version they are working on at a page level. This is adding to a management version not detracting from it. I tried to create and log in as just an author user to see if I was wrong -- but didn't see I had perms to test this. I'll look at the videos. Waaay ...waayy huge managment burden. Most writers I worked with don't even understand version control systems and you are modeling after that. IOW, I still don't see a huge advantage as an authoring tool.
Imagine, if each time you worked on a single file in a large code base you had to think about version control each time you touched the file? Moreover, you had to see all the versions each time you listed the directory? I doubt you would find a lot of coding teams that want to work at that level. For writers this is about 100x more important as many teams have trouble conceptualizing versioning as opposed to copy.
It is important that from an authoring perspective that the author can set the version on the space level and forget it --- in all ways. Writers should have to switch something in their system to reveal the version they are working in much the same way a coder has to in SVN view versions or in Git / Hg do some extra comments. It should switch at a space level or at a folder level...and at the page level, require looking at properties buried like restrictions. Right now working in the system they are in the author's face all the time.