Thread

While I think weblogs is fine from an implementers perspective, I have had some troubles explaining the concept to clients.

I always get the response: “I don’t want a blog, I want a website I can update”

While I think weblogs is fine from an implementers perspective, I have had some troubles explaining the concept to clients.

I always get the response: “I don’t want a blog, I want a website I can update”

Then don’t mention the word 😉

I never ever say anything about the underlying implementation to clients. All they really want to be able to do is to update their site. Any who do want to know the underlying technology are usually clever enough to understand the concepts. Those who aren’t I just don’t offer it up.

Just give the clients what they need to get done what they want to get done and no more unless they ask 😉

Best wishes,

Mark

I definately welcome the new change to “channels” or “sections”... like said above, anything but “weblogs”. I was hoping this would be a change made…

im used to word “weblog”. If every tags etc. changes i’ll go mad =) At the moment its better for me to use good old “weblog” because i finally am starting to “get inside” of EE and if weblog, as inside of EE codes is going to be something else, i feel like i start all over again.

If they change:

{exp:weblog:entries}

to:

{exp:channel:entries}

Worst case scenario is you end up running a Find & Replace with the CP Utility, which would take a few clicks and 1 minute of your time: 😉

Find: {exp:weblog:entries
Replace: {exp:channel:entries

Weblog is to you now that you’re within the EE framework.  But outside of EE, weblog has a very different connotation.  Something like ‘thread’ or ‘channel’ might be easier to explain in the long run.  It’s easier to drop the connotations of ‘channel’ then it is for something like weblog.

Agreed. It’s the “connotation” or variety of meanings makes “weblog” not as good a choice as Section (which is what I use) or Channel, especially for EE as a CMS app vs. a blog. EE was derived from pMachine which was, essentially and initially, blogging software, hence the carryover of “weblog.”

EE is far beyond blogging software. ‘Platform,’ anyone?

I never ever say anything about the underlying implementation to clients. All they really want to be able to do is to update their site. Any who do want to know the underlying technology are usually clever enough to understand the concepts. Those who aren’t I just don’t offer it up.

That’s a very slippery slope.  I tend not to go in with a preconceived notion that my clients aren’t clever enough to understand.  A very important part of the project planning project is for the client to understand the technology being used on his/her site.  I don’t think any content editor, regardless of technical knowledge, is effective without having some very basic understanding of the underlying architecture.  And what’s more basic in an EE context than weblogs?

That’s how my team operates anyway.  Obviously, you have a different workflow and clientele.

I agree that EE is more of a Platform than a “CMS”. I still can’t figure out why people are not pushing the “band wagon” over to get in on this product…

While I think weblogs is fine from an implementers perspective, I have had some troubles explaining the concept to clients.

I generally refer to “weblogs” as “publishing threads” when talking to clients these days and they seem to get it right away.

News publishing thread
Events publishing thread
Testimonials publishing thread

you get the idea 😊

I think we’ve actually been using ‘publishing stream’...

That term’s used elsewhere (although where exactly I can’t remember), and it seems to make sense with all of our clients.

When we’ve used ‘weblog’ in the past, we’ve explained it to clients as being a ‘container of data’ - they get that too 😊

I definately welcome the new change to “channels” or “sections”... like said above, anything but “weblogs”. I was hoping this would be a change made…

im used to word “weblog”. If every tags etc. changes i’ll go mad =) At the moment its better for me to use good old “weblog” because i finally am starting to “get inside” of EE and if weblog, as inside of EE codes is going to be something else, i feel like i start all over again.

If they change:

{exp:weblog:entries}

to:

{exp:channel:entries}

Worst case scenario is you end up running a Find & Replace with the CP Utility, which would take a few clicks and 1 minute of your time: 😉

Find: {exp:weblog:entries
Replace: {exp:channel:entries

Agree but when i have used that, there has been few times that feature doubles info, ie. i have replaced new links and after that done, there has been 2 same links. Anycase, did not remember that when i wrote my cents =)

I never ever say anything about the underlying implementation to clients. All they really want to be able to do is to update their site. Any who do want to know the underlying technology are usually clever enough to understand the concepts. Those who aren’t I just don’t offer it up.

That’s a very slippery slope.  I tend not to go in with a preconceived notion that my clients aren’t clever enough to understand.  A very important part of the project planning project is for the client to understand the technology being used on his/her site.  I don’t think any content editor, regardless of technical knowledge, is effective without having some very basic understanding of the underlying architecture.  And what’s more basic in an EE context than weblogs?

That’s how my team operates anyway.  Obviously, you have a different workflow and clientele.

Whilst I agree that it would be nice if clients understood the underlying technology the reality of all the clients I have ever worked with is that they don’t care they just want to be able to update their site. The content editors in these cases only care doing the one thing they are good at and that is writing.

Yes it would be nice if clients wanted to know more but in all the cases I have seen this does not hold true. I certainly wouldn’t ever hold out on a client and not let them know how something works if they wanted to know but what I really do is go in and get talking to the client about what they want. I am usually very good at sussing out if they are technically adept or not just in a first interview. If they are and they start asking more questions and showing an interest in the technology then I will tell them about it, if not then I don’t simply because I don’t want them getting overwhelmed in jargon that however easily you might explain it to them they just might not get.

This in my mind is dangerous because if you start explaining this to a client and you just can’t get it across to them no matter how simple you go then I feel there is a danger of losing the client. If they think in their minds that the gubbins behind the software is like astro physics then automatically they think that entering data is like that too whereas in reality all they have to do is type, darned simple!

So what I do is go in without any pre-conceived ideas as to what a client may or may not know or understand and then go from there working with them to find out just exactly what they do know or want to know.

That has always always worked for me and I am going to stick with it as I have only ever had one client that wanted to know the underlying principals of a system and even though I explained it in nearly child-like terms they just didn’t get it. It took quite a bit of proving that all they had to do was type the text they wanted into the system and it would then appear as they wanted.

Well, that’s me anyway.

Best wishes,

Mark

Rick said there will be a 1.6.5 as well as a 2.0, with something called “strict URLs”.

What about these “strict URLs” ?
Will it be possible to create routing map for urls ?
No news about a real Multi-language support ? ... don’t call those tips in the wiki real one 😉

Here’s my wild guess for strict url’s. I think the strict urls will make sure that
the template group has to be in the url. No more default templates in a default group.
This makes url’s more consistent… (it bit me before)

For instance, can you tell what will currently happen with this url, http://example.com/index.php/dance ?
Will it open the template group ‘dance’ (index), or will it show the template ‘dance’
from inside the default template-group? And what will happen if you enable 404 handling inside EE?
I think more strict means it is good practice to use ‘templategroup/template’ in my links.

Regarding the updates on 2.0 development. I would be very interested in some of
the PHP-design things you encountered during porting ExpressionEngine to CodeIgniter.

weblogs are now called channels!

That’s interesting. The EE Roadshow agenda had a talk called “Templates and Buckets: Getting Started in EE”, and I thought that perhaps “buckets” was the new name for weblogs. But “channels” is just as good or better. I wonder what the buckets are.

If they change:

{exp:weblog:entries}

to:

{exp:channel:entries}

Worst case scenario is you end up running a Find & Replace with the CP Utility, which would take a few clicks and 1 minute of your time: 😉

Find: {exp:weblog:entries
Replace: {exp:channel:entries

Come now, we wouldn’t make you manually perform a find and replace for such an important tag changing it’s name.

Come now, we wouldn’t make you manually perform a find and replace for such an important tag changing it’s name.

I figured it would be done in an upgrade process… but like I said, worst case scenario :lol:

Thanks for the response! 😊

Come now, we wouldn’t make you manually perform a find and replace for such an important tag changing it’s name.

Hmm not sure I like the sound of that. I take it that means that ExpressionEngine will automatically be changing my template code for me.

Hmm the term self-aware and images of Terminator come to mind here! 😉