Jump to content

PW Manual


Oliver
 Share

Recommended Posts

As our studio is getting close to finishing another project, we are facing the challenge to provide our client with easily understandable materials or kind of a manual on how to manage content in PW.

As I guess that this happens from time to time to you guys around here, too, I wonder if it would make sense to collaborately work on a kind of manual document explaining key actions to be done for an editor. So there could be an open document or wiki providing texts in different languages and supportive images we all could use to e.g. turn it into a nice PDF or printed handbook (yes, some clients still like paging through paper) where we just have to replace images.

I don't think this work has to be done over and over again by each one of us for his own purpose. And I'm sure, all our clients would benefit from something like this. Also it would be a nice plus for everyone thinking about using PW the first time for a client project.

  • Like 3
Link to comment
Share on other sites

I've been thinking of how to approach imparting the workings of a client's site to them. I do print design as well and I find generating PDFs a bit tedious especially if the content changes from site to site.

I had thought to tack on a /help section to the client site and use the csv importer to generate most of the topics and then modify as required.

Link to comment
Share on other sites

I was thinking of a shared base as a ressource for generating individual site-/client-specific versions from it or just link to it. In what format or media each of us provides the material to clients doesn't matter.

Link to comment
Share on other sites

For the majority of areas where things would be the same this makes sense, but as soon as you come across custom templates (most non-basic websites I guess) then there will obviously need to be some work - that said I do like the idea of a collaborative base manual from which to customise.

Link to comment
Share on other sites

Indeed - basic editing is the key. Everything from logging in, creating pages, editing and deleting pages, TincMCE fields (just the basic set of buttons would be great) and other common fields from a standard installation would be great.

If we decide to go a bit further and write instructions on how to deal with date fields etc then that's not a problem as anything that's not relevant can be deleted on a per-client basis, but takes longer to add it every time :)

Link to comment
Share on other sites

This is a great idea, folks! Of course there are various problems to solve (like has already been said - custom templates, not being too specific etc.) but most PW sites still have a whole lot of stuff in common :)

We've been planning to build something like this for our clients, and most likely still will, considering that most of them speak Finnish (and not providing any kind of guide in their own language is hardly an option.)

Anyway -- a wiki would be nice way to deal with this considering collaboration, translations and everything. I'd definitely be interested in participating in creating the material.

Link to comment
Share on other sites

Would it not be better to integrate the manual in the backend in an pw-installation? So the editor could be informed when using the backend, maybe also with contextual help.

Why not use processwire itself for the manual? If wiki-style-linking is desired, a textformatter could be used to achieve this.

Link to comment
Share on other sites

Pidelux, I also think, a wiki like manual could absolutely be built on PW itself. And in view of contextual help: why shouldn't the manual provide alternative read access to its articles via json or xml, so the information could be used by e.g. a module providing contextual help in backend?

Link to comment
Share on other sites

Great ideas here, but I'm still voting for putting up wiki site as a starting point. Developing something more sophisticated later on won't be much of a problem, but IMHO what we need now is first version - and we need it pretty quick, so that we can see how it starts gaining momentum.

When discussing the platform choices, keep in mind that most wiki platforms are exceptionally good at handling stuff like multiple editors, access restrictions and revision history - absolute necessities if we're going to have more people producing content. My experience comes mostly from MediaWiki, though, so that's what I'd suggest. It's ugly and kinda bloated but it does get things done :)

@charliez, that sounds great too, but wouldn't it provide some extra credibility if wiki site was running at manual.processwire.com or something similar? Though I'm not sure if this was what Ryan had in mind.. :)

  • Like 2
Link to comment
Share on other sites

My main concern is another bit of software to maintain - I've got experience with MediaWiki but it's definitely not fun to run when it reaches a certain size. I also don't like having different logins for different software on the same website - it should be as easy as possible for users to contribute with just one login, which is where a lot of this falls down unfortunately.

Is there not something we could do with ProcessWire? I mean, how complicated are we thinking of going with the manual? I get that wikis are great because you can discuss the page that's being edited, plus there is a revision history, but aside from the revision history (at the moment!) this sounds like something you could achieve with a PW install and the comments module. In terms of a login system it should be easy enough to tie in the forum logins with PW users.

I'd actually say that we shouldn't rush into this. I like the ideas and the momentum but I would hate for us to use the wrong software for the job (not saying my suggestion is right either, I just don't really like MediaWiki as it's old and slow - there are likely other, newer systems out there that should be considered if we were to go down the wiki route).

Edit: I was only really reading the last post so I didn't spot all the other comments saying "why not use PW?" until just now ;)

Link to comment
Share on other sites

I'm not sure the software matters so much at this point, so long as it lets us get going quickly and covers the short-term collaborative needs. The focus in the beginning should be on the editors and their short term needs. Getting the content going is a lot harder than getting the software. Content is portable. Once the content is in a good place, then we're in a good spot to put it wherever it would best serve the users (while still keeping it collaborative).

PW was not designed as a Wiki, so it'll take some work to make it behave like one. That means somebody coding it before we can populate any content. I think the content has to come before the software here. (Though if the editors actually prefer to use PW as-is rather than a real Wiki, then we'll do that). If it were just me, I would probably use PW since I don't know my way around Wikis. But PW is a multi-purpose tool, and a Wiki is a single-purpose tool that designed for the exact purpose we are looking for.

Assuming a Wiki is a better environment for the editors, my opinion is that it's a good way to get things going short term. Moving it into a PW-powered Wiki longer term would be ideal. That way we could maximize the flexibility of the content… even providing JSON doc feeds to live PW installs like mentioned above.

If we've accomplished what we want to with the content, then converting and delivering it with PW will be the easy and fun part.

  • Like 1
Link to comment
Share on other sites

Any idea what software looks interesting for this? I've also been meaning to check if there is any Wiki-type software that already integrates with IP.Board. I kind of doubt it, but just a 'nice to have'.

What do you guys think about hostname? Here are a few ideas:

  • processwire.org (already setup)
  • processwire.net (already setup)
  • manual.processwire.com
  • man.processwire.com (unix style)
  • readme.processwire.com
  • rtfm.processwire.com
  • wiki.processwire.com
  • Like 1
Link to comment
Share on other sites

Any idea what software looks interesting for this? I've also been meaning to check if there is any Wiki-type software that already integrates with IP.Board. I kind of doubt it, but just a 'nice to have'.

What do you guys think about hostname? Here are a few ideas:

  • processwire.org (already setup)
  • processwire.net (already setup)
  • manual.processwire.com
  • man.processwire.com (unix style)
  • readme.processwire.com
  • rtfm.processwire.com
  • wiki.processwire.com

Ryan,

Some googling reveals this: http://www.ipbwiki.com/ which seems to connect/integrate IP.Board and Mediawiki.

As for hostnames: i personally quite like rtfm.processwire.com (there's already rtfm.modx.com) but i'm not sure that everybody can appreciate this.

Some other options:

  • userguide.processwire.com
  • guide.processwire.com
Link to comment
Share on other sites

I think you are right that rtfm is the modx way. I don't really want to seem like we're trying to copy them on that. We probably need a term that doesn't necessarily label it as the comprehensive manual, because we have the main site docs. I kind of like the one sinnut mentioned "guide", since it doesn't infer itself to be an all-inclusive manual and it also seems more clearly distinguished from API, which is the named use by the docs on the main site. I also like "wiki", except that it says more about the software running it than it does about the content, and I'm not sure wiki means anything to the intended audience.

@Pete are you okay with MediaWiki or can you think of something better? I know you mentioned some concerns about it as things get large. I have a feeling we won't be getting that large (at least not by Wikipedia standards). And having the IPB->MediaWiki integration with the thing Sinnut mentioned seems like it would solve the multiple account issue. Still, I have no experience with MediaWiki, and it sounds like you do, so don't want to jump into it if it's going to be a bear.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Similar Content

    • By ksymmons
      Hey guys,
      As the question says, I'd really like to learn about your initial client communication workflows. In other words, what's your process like from the moment you get a request to provide a quote for a website to the moment you actually send the quote?
      My current workflow:
      A client fills out the contact form on my site to request a quote. I review the information provided and send them a Word document questionnaire with a list of questions. I ask for things like project scope, features needed, desired timeline, allocated budget, etc. They fill out the document and send it back to me. I review the information provided and make sure I've got everything I need. I write and send the quote to the client. Client accepts the quote. I send them a contract, get it signed and collect 50% of total payment. I gather some extra information from them, usually just by asking questions via email or by sending them another Word document questionnaire. I start building their site. Lately, I've been thinking about changing this workflow a bit. Currently, my online contact form has three fields: name, email and message. What I'm thinking is, what if I provide a select toggle above my form so that clients can choose between a simple, general enquiries form and a larger form (with all the questions I've got in my Word document) to request a quote? This would allow me to do away with the Word document, and would make this a one-step process.
      The reason why I haven't done this so far is because I'm not sure how good of an idea it is to have a long contact form with say, 10-15 questions. What's your take on this?
      Another thing I'm not entirely happy with is having to send them two questionnaires (steps 2 and 8). The reason why I do this is because I don't want to overwhelm them with lots of questions at the beginning, and also because, to be honest, the questions I ask in the 2nd questionnaire do not really influence pricing, as they have more to do with the nature of their business, their goals with the new site, possible corporate colours they may have, things like that.
      What do you guys think? Does my workflow seem sensible to you? Is it similar to what you do? What would you change?
      Thanks, and sorry for the brick!
      P.S. If some of you guys are willing to share your client questionnaires I would certainly appreciate it.
    • By eangulo
      Hello everyone,
      Usually in many CMS database tables prefixed or suffixed with "cache" can be manually cleared without a problem because the system will populate them on the "next page request". Actually in Processwire I am expecting this behaviour:
      [On PW 3.x]
      Manually clear table "caches" in database Go to "client" side (not in the admin panel) All references to my "/site/modules" in my template files does not work : wire("modules")->get(""), $modules->get("") and modules()->get("") PHP error:  Fatal error: Uncaught TypeError: Return value... My _init.php file are not able to find the references to my /site/modules/  The client side not working because this PHP fatal error. If I go to the admin panel "Admin -> Modules" and I trigger the action "Check for New Modules" in the top-right corner in the page, it populates the caches table with the required information and them the client side works.
      It is normal? Or I am doing something wrong ?
      A solution could be to manually call the script that the button "Check for New Modules" calls, but I want to know if  I am doing something wrong here.
      Thank you in advance guys ! 
    • By MrSnoozles
      Hello,
      this feature wish came up while I was working on my first bigger project with ProcessWire. While almost all of the CMS is very well thought out there was one thing that always kept me thinking "where should I put this?": simple page actions.
      What I mean is code snippets that belong to a page and should be run when a certain action is taken. E.g. when a user submits the form on my contact page (that has the contact template) I somewhere have to validate the form and then send it somewhere. So far I see two options to do that.
      Write a module that hooks into some methods and checks if the post data is set and if the page is my contact page
      This aproach is clean but it's usually a lot of overhead to write a module just for that Write the code in my contact.php template
      This aproach is fast but feels really dirty. It does not help to separate the logic from the design which I fear in a long term could lead to some Wordpressish code structure  
      Now since I don't have so much experience with ProcessWire there might be a chance I missed something, but then it's probably not documented obvious enough. So I thought how you improve on this problem and came to a solution, that's again really close to the syntax that jQuery provides. If we had some kind of routing system we could register those actions in any file, for example the templates _func.php
      <?php // execute this action when a post request is sent to /contact // the parameters given to the callback function probably should be different wire('request')->on('post', '/contact', function($request, $input) { // do an action } // do the action for any post request wire('request')->on('post', function($request, $input) { // do an action } // do the action for get requests on contact pages wire('request')->on('get', 'template=contact', function($request, $input) { // do an action } // do the action on ajax-GET requests wire('request')->on('get.ajax', '/contact', function($request, $input) { // do an action }  
      Is that something that could improve the work with ProcessWire? What's your honest opinion about it? If that's a useful suggestion I would like to help with the implementation.
       
      Regards
      Alex
    • By cosmicsafari
      Hi all,
      Just wondering if its safe to delete the content of the cache table manually within the database?
    • By Chris
      short story:
      think of a radio button mechanic in the background, but ui-wise you present images with captions as "buttons".
      for instance i whant to be able to let admins change some visual themes of a single page, with different background and formating for each, i could place screenshots thumbs with a short caption. so the admins are able to se a preview image and know better what this setting does.
      therefore it would be needed to define images for an input field, during the field creation. maybe someone likes the idea and is able to do it? 
×
×
  • Create New...