Making PW more userfriendly

[Nico Knoll]

He probably used the default one. I didn't make the site. They had another company doing it for them.

[horst]

I like fish... Can you cook Ryan?

you need learn how to fish?  OR   you should learn fishing? 

[pwired]

Posts like 144 should not fade away in the forum. Many already have. Summarizes and clarifies so much.

Will find something.

[marcus]

Posts like 144 should not fade away in the forum. Many already have. Summarizes and clarifies so much.

Will find something.

Oh yes - Ryans post screams to be put on a subsite like processwire.com/philosophy.

[pwired]

processwire.com/philosophy.

Nope, have something else in mind.

[Nico Knoll]

Nope, have something else in mind.

Like what?

[pwired]

Like one of your cool dedicated sites to pw

[onjegolders]

ProcessFish

[ryan]

A few updates in response to the PDF that was posted earlier. More to come, but this is a start. Currently these are just on dev, but will be merged to master soon. 

The main README file has been updated with a link to the HTML version at the very top. I honestly think including a README.html file in the core itself is bad form because it reveals exactly what software is running the site. Some might have noticed our README files are generally blocked from http access (by the .htaccess file) for this very reason. So I think putting a link to the HTML version of the document at the top of the Markdown file is a good compromise. 

The default site profile has been updated with its own README file and separately hosted HTML version: Introduction to the default site profile, which goes in depth in explaining exactly how the site profile works. The template files have also been updated, telling the user to see README.txt for more information (though not sure that's really necessary).

[woop]

Ryan, great work as always! I know the character in my PDF was a bit over the top but I don't think it's unlikely to think that people who've outgrown drupal/wordpress would have a similar experiences when first trying Processwire 2.5. The simplicity of PW's API combined with PW 2.2's "direct output" strategy is what tipped me over. It was so easy to get started I felt it was worth the effort trying to rebuild a better version of my site from scratch using PW. Haven't looked back since. The delayed output method is, in my honest opinion, a step backwards. It may be less scalable then the direct output method but coming from Drupal where it's common to put PHP snippets in the admin – it's a huge improvement and extremely intuitive. However, the new READ ME you just added will make this less of a problem

Cheers!

[Nico Knoll]

The GetStarted module has it's own thread now: https://processwire.com/talk/topic/7666-getstarted-a-module-that-helps-first-time-users-to-understand-processwire-faster/#entry74360

[ryan]

The simplicity of PW's API combined with PW 2.2's "direct output" strategy is what tipped me over. It was so easy to get started I felt it was worth the effort trying to rebuild a better version of my site from scratch using PW. Haven't looked back since. The delayed output method is, in my honest opinion, a step backwards. It may be less scalable then the direct output method but coming from Drupal where it's common to put PHP snippets in the admin – it's a huge improvement and extremely intuitive. 

 

Just to correct the quote above, delayed output is more scalable, not less scalable. Direct output is what doesn't scale, but it doesn't really matter when it comes to the default profile. 

 

I have worried about this aspect a little bit: making something as easy-to-understand as possible, versus showing what is a best practice. Delayed output is just as simple as direct output (not to mention it uses a lot less code), but it's not as easy to understand at the very beginning. 

 

On one hand the PHP developers evaluating ProcessWire cringe when they see the direct output method used in the old default (now classic) profile. On the other hand, beginners find it easier to relate to since it's common in other platforms. Both are our audience. If people think delayed output isn't beginner friendly enough, perhaps we need to have two versions of the default site profile. A beginner edition and an intermediate edition. 

 

Attached is a beginner edition of the default site profile. @Woop if you or anyone else gets a chance to take a look, please do and let me know if you think this is a more beginner friendly approach. I think it probably is, even if it isn't an approach I'd suggest someone use for anything but smaller sites. 

 

site-beginner.zip

 

To install, just grab a fresh copy of ProcessWire 2.5.0+. Place the contents of the zip in a /site-beginner/ directory and then load the installer from your browser. For site profile, select "Default (Beginner Edition)". 

 

The readme file in /site/templates/ has also been updated in this profile to reflect the structure of the template files. 

 

As for re-writing the text in the default profile (something mentioned way earlier) I agree on this and I need to talk to Joss. But I think getting the template files as simple as possible is a bigger priority at the moment. I think a lot of people installing CMSs for evaluation are more interested in the system and templates than in what demo content is in the fields. But for those that do read it, we can do better. 

[diogo]

I think it makes sense to keep the direct output, since more advanced developers will most probably start with a blank state anyway.

[Joss]

As for re-writing the text in the default profile (something mentioned way earlier) I agree on this and I need to talk to Joss.  . 

You have my email  

[woop]

I think the rewrote looks really good. like diogo pointed out, experienced PHP devs will probably see the possibilities PW brings and use their own strategy. having the "direct output" as the default profile and then adding the "delayed output" version as an alternative seems like a great compromise (if you're ok with maintaining both). 

[davo]

Just to add my two pennies worth...

I'm not a coder by trade, but used to make many joomla sites for hobby money. But, by virtue of not being a coder I  was restricted to what modules and components other more competent people created. This only caused me more problems when the core upgraded  etc leaving me with out of date components and a vulnerable site. (and some egg on my face)

I switched to PW after recommendation by a friend which turned out to be the best thing I could have done. With practically personal tutoring by members here (Adrian, Ryan, Joss, Pete, sinnut etc (sorry for missing out so many)), I've become competent in using the api and basic php.  I now don't need a component to make a blog, photo gallery, complex database, I make my own. The biggest advantage of this is I know exactly how they work, I know how to adapt it and I most of all it won't become obsolete when the core gets upgraded.

What makes a coder?

$x = "any";

$y = 1;

$z = "you";

echo "$x" . "$y";

$y = $y+$y;

echo "$z" . $y;

Would that even work? lol

WP/Joomla and drupal all have a targeted audience... but I belong here lol.

[diogo]

http://www.tehplayground.com/#91kqu1Uyz

It works, but doesn't make much sense

[davo]

must be down to my tutors lol.

$x = "any";
$y = 1;
$z = "you";
 
echo "$x" . "$y";
 
$y = $y+$y;

echo "even" .  $z . $y;

[diogo]

Maybe like this? http://www.tehplayground.com/#PF1X9PHPL

[OrganizedFellow]

Posts like 144 should not fade away in the forum. Many already have. Summarizes and clarifies so much.

Will find something.

We have Area51.

Heinz57.

And the Fibonacci Sequence.

We now have Post144.

BTW:

You like fish?

I like Turtles. Yes. I said Turtles.

[Peter Falkenberg Brown]

Dear Ryan and All,

Ryan wrote: You do have to come from the point of view of "I want to create and have the system adapt to me" rather than "I will create something based on what the system provides." If you already know what you want to create and it's something unique, you won't find a simpler path to get there than PW. ... Our audience consists of those that want to have a system support their original creation rather than mash up an existing creation.

The above quote is what brought me to PW, and what makes me stay.

I've built three magazine style "CMS" sites with ProcessWire, and it was a joy.

But I've also built an email-driven, web help ticket system, as well as an entrepreneurial, formula-based business application to vet new startup concepts. (Both apps are non-public, user-login-only apps.)

Once I understood ProcessWire's methodology and API, I was free to focus on the design and implementation of the above custom business applications without worrying about ProcessWire getting in the way -- because it didn't. I wrote PHP template scripts with the API, using the page-based methodology, and it was a dream come true.

I shudder at the idea of trying to replicate the above web database applications in WordPress or Drupal. Someone probably could, and they're welcome to it -- but it "ain't me."

Also: I've probably missed a post that you've already written, but do you have a post that thoroughly explains the benefits, virtues and rationale behind using the "virtual table method" PW employs, by stitching one field per real table into field templates?

I'm comfortable with it now, but for folks who are used to regular data tables, with a set of fields in them, PW's method is very new and very different. A prominently placed white paper on that would be very helpful, I believe.

Kudos, Ryan!

Peter

[pwired]

Talking about it, this would be a good slogan:

Free your website with Processwire - - - - - -

[bernhard]

Also: I've probably missed a post that you've already written, but do you have a post that thoroughly explains the benefits, virtues and rationale behind using the "virtual table method" PW employs, by stitching one field per real table into field templates?

I'm comfortable with it now, but for folks who are used to regular data tables, with a set of fields in them, PW's method is very new and very different. A prominently placed white paper on that would be very helpful, I believe.

i would be very interested in that

[hdesigns]

i would be very interested in that

Second that

[Pete]

Here you go guys: https://processwire.com/talk/topic/2387-the-structure-of-fields-and-templates/?p=22762 (found via a link halfway down this article: http://www.flamingruby.com/blog/anatomy-of-fields-in-processwire/ )

I know ryan has explained this several times over the years but I agree that as one of the real "what the heck?" points that come up when you're first exploring ProcessWire some page dedicated to it on the site and linked to wherever fields are mentioned might not be a bad idea