Where are you with mobile?
Daniel Goddard | London Websites
The "where are you with mobile" question brings a "too early to call"
answer from many people I ask, some even give a dumb look as if to say
"why, should I care?".
This answer brings the question round to another question, "should I
care about mobile?" - the answer depends, I believe, largely upon what
your stats tell you.
For my main website, we have an average 20% of visitors come from
mobile devices, most notably Blackberry, iPhone, iPad, and a range of
Android devices. Our bounce on that group is double that of desktop
version visitors.
So, with no knowledge of designing websites for mobile phones, I
simply Googled for two things: 1) Mobile web content guidelines (found
at w3c.org) and 2) Mobile website templates (found at qrdvark.com).
Both were free, which is ultimately better than a kick in the teeth.
Fast forward two weeks and the bounce rate from mobile visits to my
mobile site (m.londonevents2011.com) vs the desktop site
(londonevents2011.com) has gone significantly down.
I haven't put advertising on the mobile site yet, but one day of
getting dirty with w3c and a few tasty lines of xhtml have paid
dividends.
So when somebody asks you, "where are you with mobile?" At least you
can have some idea what the benefits are to your visitors, and maybe
to your potential visitors. Maybe your one step of the game and
already have a mobile site, in which case please feel free to share
the URL.
Thanks, Dan
On 29/08/2011, Chris Turner <junct...@gmail.com> wrote:
> Hi all,
> The company I work for is putting together some FAQ content and much
> of it has been written by a combination of folks from technical,
> marketing and business stakeholders. As you can imagine, it's a hodge-
> podge of approaches.
>
> Does anyone have any recommendations for articles about writing FAQs
> that I could share with the content creators to try and get us on the
> same page? I'd also appreciate it for any tips or suggestions since it
> appears that I'll be reworking much of that content in the end.
>
> Thanks,
> CT
>
> --
> You received this message because you are subscribed to the Google Groups
> "Content Strategy" group.
> To post to this group, send email to content...@googlegroups.com.
> To unsubscribe from this group, send email to
> contentstrate...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/contentstrategy?hl=en.
>
>
--
Sent from my mobile device
Kind regards,
Daniel
Daniel Goddard
Web Content Editor | London Events 2010
www.londonevents2010.com
eve...@londonevents2010.com
+44 (0)7561 313 198
Noz Urbina
"I find quotations at the bottom of email signatures somewhat trite..."
Daniel Goddard | London Websites
person Google's it on their phone. Imagine the difference between
having a mobile friendly site as opposed to something that take a few
mins to load and you have to zoom x3 and scroll. Which is more likely
to convert customers? I'm also staggered about the amount of apathy
and complacency when it comes to mobile. It's the future in content
strategy and people across the board are, in the majority, almost
ignoring it.
Noz Urbina
Paola Roccuzzo
First off, the changes in IT right now are challenging the very
semantics of the word "content".
As most of us have at least some sort of "writing" background, I might
feel tempted to say that most of us also work on the assumption that
"content" = "copy".
(Don't we already make a distinction between "assets" and "copy"?)
And now that content is finally being aknowledged as an important part
of every project, we might soon have to deal with the fact that it
doesn't mean the same thing anymore.
I was recently involved in the design of a multi-channel appstore. One
of the channels was mobile.
It was funny how, every time the word "content" came up, it could mean
indifferently the app as a product, the copy describing the app, or
the artifact itself.
But I think that it made perfect sense. Apps are the new content for
mobile, and it is not clear where content professionals will fit in in
the product lifecycle.
As for my personal experience, "content" (as we currently define it)
was not even considered for the mobile channel: UX would take care of
everything.
As this was basically an E-commerce project, and since no particular
request was made for mobile, I made sure that at least the catalog
could accomodate all channels without any particular overload for the
organization, and personally engaged with UX to make sure their
wireframes did capture that. Not much else I could do in that regard.
And this should make us think hard about what kind of added value we
can give to this new "content".
I have two or three ideas, but they are still very foggy--I would be
interested to know if anybody had my same feelings.
Paola
the Baraness
I've worked on a mobile strategy for a large financial services client. We created a content plan with a trimmed version of the web site. Very responsive design friendly. See Ethan Marcotte's latest from A List Apart.
Cliff Tyllick
I don't know if he's on this list, but the first person I heard voicing that perspective is Luke Wroblewski. In fact, I think he wrote the book on the mobile-first approach to Web design.
;-)
Rick New
Cliff Tyllick
Paola wrote:
Absolutely! This came up in Kristina's panel at SxSW-Interactive. Wrangling over the concept generated quite a bit of discussion.
Paola:
As most of us have at least some sort of "writing" background, I might feel tempted to say that most of us also work on the assumption that "content" = "copy". (Don't we already make a distinction between "assets" and "copy"?) And now that content is finally being acknowledged as an important part of every project, we might soon have to deal with the fact that it doesn't mean the same thing anymore.
Cliff:
If any of us haven't yet, we absolutely should. As you mentioned in describing your project with the multi-channel appstore, "content" could "mean indifferently the app as a product, the copy describing the app, or the artifact itself."
You feel that that is as it should be, and I wholeheartedly agree. In fact, I never quite understood the separation of content into "the stuff we put into the content management system" plus "assets." Where I work, "assets" are forms that people must use to get permits or make reports that are required of them by law. It also means the publications and PowerPoint presentations that help people figure out which forms they need to complete, when, and why. And there's probably other "stuff" among our collection of "assets."
And don't even mention the data in our various databases. So that's really four divisions:
- Words and images on a Web page, which go through a workflow in our content management system before they see the light of day. Everyone has words, images, or both on their websites. But to me, these are mainly the words that help people get people where they think they want to go and then figure out whether they're in the right
place once they've gotten there. So think of these as your navigational pages plus, perhaps, your landing pages.
- PDFs, PowerPoint decks, Excel files, Word documents, and the like, some of which go through an editing process (not the same as our CMS workflow) but many others of which are simply created by a subject-matter expert and put online with no more than a cursory review. In e-commerce, you might have a number of parallels to this content, but one that occurs to me is the information about your products — specs, descriptive copy, and so forth. And to some extent, your landing pages and the HTML pages they lead to might fit here, because we have an awful lot online in one of these formats that really should be in HTML.
- Databases, which are the realm of programmers and reflect their concept of efficiency. In e-commerce, think of this as being your gallery of merchandise — not the merchandise itself, but the area where
people find it. And widgets, including shopping carts, might fit into this area, too. If you couldn't make it happen with an HTML template, it might belong here.
- The individual bits of data, which are the realm of subject-matter experts and are labeled and organized according to their mindsets. In e-commerce, this would be the products or services you sell. Not the physical goods, but the specific words and images that represent them at the point at which the customer decides whether to add them to a shopping cart.
To bring the discussion back to mobile strategies, that concept has been a major barrier to working ours out. When we think of bringing our "website" to mobile, nothing we currently think of as our "website" will fit. We can't just port it over there, we can't shoehorn it in, and we can't even imagine reconfiguring it to make it work.
So we started by trying to figure out which parts of that "website" people are most likely to want to get to when they might be using a mobile device. We did surveys of people inside our organization as well as people who have to do business with us, asking them whether they had ever tried visiting our site on a mobile device. If they had, we asked them what topics they were looking for when they did. If they hadn't, we asked them what topics they might look for if they ever did go to our site on a mobile device. And now we're designing a simpler, more text-based, presentation to deliver to people using mobile devices.
I seem to be the only one in our organization who has read Ethan Marcotte's and Luke W's work. I wasn't invited to participate in any stage of this project — probably because I would have insisted that we consider that what people tell us they do or would do is almost never a close approximation of what they actually do, and think not about how we serve all those HTML pages but how we help people find (and, in some cases, discover) our content. And when I say "content," I mean "the stuff we have that they need so they can do whatever it is they must come to our website to do."
Yes, that's all four of the bullet points I listed earlier.
And until we start considering all that content, the cases that cause people to need it, and all the data we can gather about how they're using it now, we're going to be stuck in this rut, sniffing your device and delivering a .mobi subdomain if it seems to us that it's mobile.
So, yeah, Noz and Dan — we're lost, and unless something changes, I'm afraid we're never going to find our way.
I hope we're the exception, but I doubt it.
Cliff
Daniel Goddard | London Websites
1. A mobile specific website
2. A website designed to render correctly on mobile devices
3. A mobile app
4. A website designed without mobile usability in mind, but that can
be viewed on mobiles if using a zoom feature.
My preference, especially when considering commercial objectives, is
number 1. A mobile specific website, with content displayed and copy
written specifically for mobile users.
Albeit a Nielsen fan, the mobile article on the useit site still
displayed small text which required the zoom and scroll features.
At Internet World in London I met a guy whose company had a list of
every mobile device created on the open market, with dimensions and
parameters for each device, and a method of rendering content
specifically for each mobile device.
> * Words and images on a Web page, which go through a workflow in our
> content management system before they see the light of day. Everyone has
> words, images, or both on their websites. But to me, these are mainly the
> words that help people get people where they think they want to go and then
> figure out whether they're in the right place once they've gotten there. So
> think of these as your navigational pages plus, perhaps, your landing pages.
>
> * PDFs, PowerPoint decks, Excel files, Word documents, and the like, some
> of which go through an editing process (not the same as our CMS workflow)
> but many others of which are simply created by a subject-matter expert and
> put online with no more than a cursory review. In e-commerce, you might have
> a number of parallels to this content, but one that occurs to me is the
> information about your products — specs, descriptive copy, and so forth. And
> to some extent, your landing pages and the HTML pages they lead to might fit
> here, because we have an awful lot online in one of these formats that
> really should be in HTML.
>
> * Databases, which are the realm of programmers and reflect their concept
> of efficiency. In e-commerce, think of this as being your gallery of
> merchandise — not the merchandise itself, but the area where people find it.
> And widgets, including shopping carts, might fit into this area, too. If you
> couldn't make it happen with an HTML template, it might belong here.
>
> * The individual bits of data, which are the realm of subject-matter
Noz Urbina
Daniel, I'm going to be discussing this a bit in at cs forum next week. I may quote you. I agree essentially, but how do you make it feasible to create that separation, and keep content and messaging synchronized?
I find that is the big challenge that holds most of our clients back.
On Sep 3, 2011 11:55 PM, "Daniel Goddard | London Websites" <londonw...@gmail.com> wrote:
I see four mobile solutions:
1. A mobile specific website
2. A website designed to render correctly on mobile devices
3. A mobile app
4. A website designed without mobile usability in mind, but that can
be viewed on mobiles if using a zoom feature.
My preference, especially when considering commercial objectives, is
number 1. A mobile specific website, with content displayed and copy
written specifically for mobile users.
Albeit a Nielsen fan, the mobile article on the useit site still
displayed small text which required the zoom and scroll features.
At Internet World in London I met a guy whose company had a list of
every mobile device created on the open market, with dimensions and
parameters for each device, and a method of rendering content
specifically for each mobile device.
On 03/09/2011, Cliff Tyllick <cliff....@yahoo.com> wrote:
> My responses follow each of Paola...
--
Sent from my mobile device
Kind regards,
Daniel
Daniel Goddard
Web Content Editor | London Even...
You received this message because you are subscribed to the Google Groups "Content Strategy" group.
...
Rick New
Many people predict that mobile devices will be the only important user interface platform in the so-called "post-PC" future. Some even recommend designing websites for mobile first, and then modifying the design for the desktop PC as an afterthought.
I disagree.
--
You received this message because you are subscribed to the Google Groups "Content Strategy" group.
Noz Urbina
I think that quote takes it too far. Designs are easier to flesh out for the larger platform than shrink and I think that makes for a logical process. But I don't agree at all we are moving to a post pc era. I think we're are seeing an additional non WWW electronic delivery channel which calls for a real single sourcing strategy and process.
On Sep 4, 2011 12:25 AM, "Rick New" <ric...@firstandunion.com> wrote:
> Nielsen also takes exception to the "mobile first" approach.
>
> Many people predict that *mobile devices will be the only important user
>> interface platform* in the so-called "post-PC" future. Some even recommend
Rick New
Noz Urbina
I think that that quote he's quoting takes things too far. So whomever he's quoting or paraphrasing is simply out to lunch and forgot to take their wallet.
Rick New
Noz Urbina
--
You received this message because you are subscribed to the Google Groups "Content Strategy" group.
To post to this group, send email to content...@googlegroups.com.
To unsubscribe from this group, send email to contentstrate...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/contentstrategy?hl=en.
Matt Moore
Now in some situations, apps rock. But apps are not cheap to build (esp. if you want them to work on multiple platforms). And as others have said, an app is only one way of serving content to users with mobile devices.
I'd prefer organisations to take a more thoughtful approach to this:
- Do we know how many of our visitors are using mobile devices already?
- Do we know which parts of our site are mobile hotspots?
- Do we have some understanding on the mobile context in which that content is being used?
- What is the most (cost) effective way of serving up this content to these users in a mobile context? i.e. mobile-optimized pages, mobile sub-site or app
Getting answers for the first 2 questions should be trivial. Question 3 might require a bit more work. But we shouldn't hit Q4 until we have answers to the previous questions.
Rahel Anne Bailie
Cliff Tyllick
Best,
Cliff
Daniel Goddard | London Websites
just as important as current mobile visitors. I'm often in and around
London looking for store locations and opening times, and am staggered
that the overwhelming majority of top SERP content is not from
official websites. Have the major brands not considered how their
customers interact with their content?
Mobile store locator software is another gaping hole, I don't
understand why major brands don't focus on this? If one area of
content is vital to a commercial outlet's mobile strategy its telling
customers how to find them. They must be losing out on vast revenue
streams from frustrated customers who can't find the right content.
Burton menswear is the worst offender, I Googled on the Crackberry
for their store locator and was presented with a page that said
"welcome to the Burton Store Locator" -" gave me a long shpeel about
how great it was, then gave a link to the actual facility...which
didn't work. Lost customer. Lost £200 to a rival.
Marketing Week has all the stats, but they seem to go largely ignored.
> --
> You received this message because you are subscribed to the Google Groups
> "Content Strategy" group.
> To post to this group, send email to content...@googlegroups.com.
> To unsubscribe from this group, send email to
> contentstrate...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/contentstrategy?hl=en.
>
>
--
Geoff Coats
while and perhaps *for that reason* I'm missing something really
obvious.
When I saw this thread pop up, I thought I knew what the discussion
would be. Turns out I was wrong. So that makes it really interesting
for me.
What I find interesting is that some people are still talking in terms
of a website *and* mobile site. In our studio -- and this may just be
because of our client mix -- we crossed a very important bridge about
9 months ago and made the determination that this dichotomy was no
longer relevant: That to build a website *is* to build a website that
is responsive and which serves up all the *same content* to all
visitors regardless of the device they approach from. Of course, how
and where that content appears will be tailored to the device they use
to approach the information but a visitor can always find the
information (hopefully -- if we've done our job).
To be clear, we have been thinking about these issues longer than the
past year. But previously we would have discussed whether mobile was
in-scope or out-of-scope (buffet style). Now we don't even ask our
clients. We start from the assumption that the web *is* mobile, *is*
tablet, *is* laptop, and *is* widescreen. Now the design question
comes down to how do we design based on this given.
We also believe -- and I'll be happy to learn why we're wrong ;) --
that this is also doing the clients a service in the long-term as it
eliminates the mental overhead and accompanying financial overhead of
trying to remember which content is where and what that means for
updating content.
Additionally, it avoids what I have come to think of as the AirBnB
problem. I love AirBnB. I am an AirBnB host, in fact. And they get 92%
of everything right -- so I'm not beating up on them. But one thing
has consistently driven me crazy as a loyal user: they have an iPhone
app. So far so good. Except that the app *assumes* I don't need to
access certain information that I can see on the "website."
Unfortunately two things converge here: 1. They are wrong in their
assumptions about what I want to see. And 2. -- I can never keep
straight which information I *can't* get on the app. So I am
constantly logging into the app searching through all the various
options only to finally realize after wasting 5 minutes that I have to
leave the app and go to the website -- where I generally see the
message about the cool iPhone app they have and would I like to
download it since I'm coming from my iPhone. Not a deal killer but
definitely brand friction.
Being rather new to this list, I notice that while many projects are
discussed I don't find many links to people's actual work. I'm not
sure if this is a rule or just that often it can't be discussed. I am
going to risk violating the rule -- if there is one -- as I think that
seeing examples of what I'm discussing above could help the
discussion. So please forgive me if I am crossing a line.
Here are three sites we have done over the past few months which
illustrate -- to greater and lesser success -- the ideas I'm talking
about. If you access any of these sites on a desktop, tablet, and
mobile (and even landscape vs. portrait versions of some) you will see
how we have delivered the same content to all users but attempted --
again not saying we knocked all these out of the park! -- to
understand the limitations and opportunities of each device.
Bike Easy (New Orleans non-profit)
http://bikeeasy.org/index.php
An Architecture Portfolio Website
http://www.ggbarchitects.com/portfolio/
And our own studio website:
http://zandenewman.com/
Granted none of these are 60,000 page sites but I'm very interested to
learn about the limits of this approach and where / why people believe
it breaks when attempting to scale.
As always, thanks for the great discussions!
Best,
Geoff Coats
Daniel Goddard | London Websites
this discussion (and apologies for any misconception that I was trying
to self promote in the original post - we are all learning).
I viewed all three sites, clicking a second page on each, via a
Blackberry, and here's some feedback.
Site 1 - 20 secs to load
Site 2 - 50 secs to load
Site 3 - 1 min 25 seconds to load
All three sites appear to be using the same template. Text displays
almost perfectly, while the final navigation tab on each site jumps to
a second line. The images (particularly logos) are not distorted but
are probably too large.
Its a much better effort than most however I would questioned whether
I'd wait for the page loading if I 'wanted' some passing info as
opposed to 'needing' it?
Based on these three sites, and forgive a criticism from an idealist,
but my preference is still to build mobile specific websites.
One question though, Geoff, how do you test content on all devices? Do
you have a list of devices with dimensions, or all the devices in
house?
Thanks again for a great post.
Dan
Noz Urbina
Odd - my last post (quoted below) doesn't seem to have made into the mail trail, yet Cliff got it... I've never seen Google groups just 'omit' something like that...
> ________________________________
> From: Noz Urbina <b.noz....@gmail.com>
> To: content...@googlegroups.com
> Sent: Saturday, September 3, 2011 7:06 PM
> Subject: Re: Where are you with mobile?
>
>
> Hi Cliff,
>
> Because of the length of your post, I in fact circled 'round now and read it. I want to thank you so much. This exactly the situation I've been perceiving and I wanted to have someone else pipe up so that I can quote someone else besides my own experiences next week. I hope some of the list members will be there as I'm very interested to discuss this.
>
> You've broken it down very nicely. I have so many places where I want to link out to blog posts I've done where I'm praying for people in the community to say things like that and you've wrapped it all up nicely in a single email.
>
> think you're not at all the exception and can't agree more that everyone, and I thinkespecially everyone on groups like this one, will need to grapple with and then take action on some key messages which I'll highlight from your mail with my own supporting thoughts:
>
> We need to:
>
>
> 1) realise that if content strategies are done with single-sourcing in mind than this situation:"When we think of bringing our "website" to mobile, nothing we currently think of as our "website" will fit. We can't just port it over there, we can't shoehorn it in, and we can't even imagine reconfiguring it to make it work." can actually be avoided.
>
> 2) realise that all those 4 points are all content, your definition is beautiful: "the stuff we have that they need so they can do whatever it is they must come to our website to do."
>
> 3) within that definition of content, realise customers don't respect the separations between the four points AT ALL. The fact that's just how agency-client relationships, budgets, departments or project scopes are built is irrelevant in the customers' minds. In fact, if they get any wind of that, it badly impacts the brand in question instantly. My favourite comparison is when we call up a bank and we give all our details, client and security data to one operator, and then they transfer us to another department, and (after having been on hold 5 minutes) they more or less politely say, 'So who are you? And why am I talking to you? I'm going to need all your details please!' Rage is instant and deep.
> 4) accept the conclusion as gospel: "until we start considering all that content, the cases that cause people to need it, and all the data we can gather about how they're using it now, we're going to be stuck in this rut"
>
> Amen, brutha!
>
> Must sleep now... :(
>
>
> On 3 September 2011 20:16, Cliff Tyllick <cliff....@yahoo.com> wrote:
>
> My responses follow each of Paola Roccuzzo's points I feel I can add to.
>>
>>Paola wrote:
>>
>>First off, the changes in IT right now are challenging the very semantics of the word "content".
>>
>>Cliff:
>>Absolutely! This came up in Kristina's panel at SxSW-Interactive. Wrangling over the concept generated quite a bit of discussion.
>>
>>Paola:
>>As most of us have at least some sort of "writing" background, I might feel tempted to say that most of us also work on the assumption that "content" = "copy". (Don't we already make a distinction between "assets" and "copy"?) And now that content is finally
> being acknowledged as an important part of every project, we might soon have to deal with the fact that it doesn't mean the same thing anymore.
>>
>>Cliff:
>>If any of us haven't yet, we absolutely should. As you mentioned in describing your project with the multi-channel appstore, "content" could "mean indifferently the app as a product, the copy describing the app, or the artifact itself."
>>
>>You feel that that is as it should be, and I wholeheartedly agree. In fact, I never quite understood the separation of content into "the stuff we put into the content management system" plus "assets." Where I work, "assets" are forms that people must use to get permits or make reports that are required of them by law. It also means the publications and PowerPoint presentations that help people figure out which forms they need to complete, when, and why. And there's probably other "stuff" among our collection of "assets."
>>
>>And don't even mention the data in our various databases. So that's really four divisions:
>>
>> * Words and images on a Web page, which go through a workflow in our content management system before they see the light of day. Everyone has words, images, or both on their websites. But to me, these are mainly the words that help people get people where they think they want to go and then figure out whether they're in the right place once they've gotten there. So think of these as your navigational pages plus, perhaps, your landing pages.
>>
>> * PDFs, PowerPoint decks, Excel files, Word documents, and the like, some of which go through an editing process (not the same as our CMS workflow) but many others of which are simply created by a subject-matter expert and put online with no more than a cursory review. In e-commerce, you might have a number of parallels to this content, but one that occurs to me is the information about your products — specs, descriptive copy, and so forth. And to some extent, your landing pages and the HTML pages they lead to might fit here, because we have an awful lot online in one of these formats that really should be in HTML.
>>
>> * Databases, which are the realm of programmers and reflect their concept of efficiency. In e-commerce, think of this as being your gallery of merchandise — not the merchandise itself, but the area where people find it. And widgets, including shopping carts, might fit into this area, too. If you couldn't make it happen with an HTML template, it might belong here.
>>
>> * The individual bits of data, which are the realm of subject-matter experts and are labeled and organized according to their mindsets. In e-commerce, this would be the products or services you sell. Not the physical goods, but the specific words and images that represent them at the point at which the customer decides whether to add them to a shopping cart.
Cliff Tyllick
- Noz, you're the second person I've encountered who has not been able to see his own messages to a Google group. In the other case, the change was sudden, seemingly without his having done anything (as in changes to his profile or preferences) to trigger it. He ultimately unsubscribed and then resubscribed to fix it. :-/
- Point of clarification: It was Dan, not I, who said, "My preference, especially when considering commercial objectives, is [a] mobile specific website, with content displayed and copy written specifically for mobile users."
After all, as Geoff pointed out, customers who find something on our site when using their desktop shouldn't be told "you can't get there from here" (or, more likely, left to figure it out for themselves) when they later try to find the same content from their mobile phone.
Dan, I'm amazed to learn of the long load times you experienced. That definitely shouldn't be what happens. I would have bailed and looked for the content elsewhere — which might mean that I will get it from a competitor instead.
Cliff Tyllick
From: Cliff Tyllick <cliff....@yahoo.com>
To: "content...@googlegroups.com" <content...@googlegroups.com>
Sent: Sunday, September 4, 2011 8:01 AM
Rahel Anne Bailie
Clare O'Brien
So, this is the thing: ‘Platform independence is all about separating structure from presentation’. What a great discussion. This isn’t really about mobile per se. This about all the ‘stuff’ in Cliff’s 4-point list (plus more). It’s about the point Noz made: What is the ‘site’? And it’s very much about point 3 in Matt’s list: Do we understand the context of how the ‘stuff’ that people want / need is being used?
It’s too easy to get snagged by the technology, the containers for all this content stuff. When actually it’s really about making sure that people can access the stuff they want when they need it and that will change individually depending on things like the point in the customer life-cycle, what bit of technology they have to hand and what they’re doing at that moment (like Matt wanting to locate a particular shop for a distinct reason on that day in that location). The context.
But it’s also very easy to see why this snagging happens. That’s what’s best understood – how to technically put this stuff here or there or over there. What’s least understood is how to make stuff available everywhere.
Organisations need to change the way they think and that’s hard. In the past it’s always been so simple. ‘I distribute these widgets and the supply chain works this way and therefore this is how I structure my business to best optimise that for profitable gain’. OK – massively simplified, but I’m sure you know what I mean. Now though, in this unpredictable and digitally challenging world, the widget supply chain has completely changed its character allowing customers far greater control. Yet organisational structures remain the same – built to solve distribution problems of the past, not tackle the new and future challenges like how can customers easily access what’s on offer.
What’s this got to do with content? Well, just about everything because ‘content’, or ‘stuff’, is what people want or need from you and this fluid new supply chain with an unpredictable future (platforms will continue to proliferate) is as much a part of the content as the widgets and services it makes accessible. Content is business and business is content.
And business in the future is about access not distribution. It’s about letting customers buy from us easily, rather than selling to.
That’s a pretty fundamental shift in business thinking and it won’t happen overnight, but to manage content so it works the way that we understand it has to, the whole business needs to think this way. That’s change and that means engaging the c-suite in this conversation. Perhaps the great platform proliferation will help? Managing content separately for each platform is expensive and untenable. The only affordable way to make content work wherever it needs to be is by developing platform neutral or independent content strategies (as Geoff has already started doing whether the client wants it or not). And to make that work properly we HAVE to understand things like context of use and customer life-cycles.
We need to be talking more widely about digital strategies. Talking content to the boardroom won’t help them understand quite how big a shift their business thinking needs to make. Talking business risk will help them listen and understand – and I mean $$$ and £££-level risk.
Geoff Coats
words. No worries at all re: criticism -- I'm a recovering academic so
I see this type of discussion as critical to the learning process. And
I am definitely in learning mode.
I want to look into the load times. I haven't seen times like that
previously and I can't reproduce them but I don't have a blackberry
handy. Thank you for that info.
One caveat: I am not the code ninja here so I am not 100% the person
to answer all technical implementation questions. But I do work
closely so here is what I know:
RE: All three sites appear to be using the same template.
Not precisely. They are all using a common framework for development
but every site we build is a customized CMS (usually building off
Expression Engine) and custom front-end templates because each client
and business model are unique. This might be splitting hairs but I
think it is an important distinction from a strategy point of view.
RE: how do you test content on all devices?
We don't have every device in house for testing -- and part of our
philosophy is that the idea that there is a fixed set of devices is
the wrong way to think about it. Even if we had a full suite of
hardware in-house -- we don't know what is going to be introduced in 6
months, 9 months, next year. So we are trying to get out of the
"develop for Explorer and develop for Netscape model" and think about
the data differently. The worst thing that could happen for our
client's businesses and for the web in general, in my humble opinion,
is an inadvertent return to 1999 and the bloated development /
maintenance costs associated with having to develop device specific
code over and over again. I think everyone here is _pretty much_ on
the same page but just to articulate it clearly there it is.
With this in mind, we make a handful of decisions about screen
resolution break points and then develop data, visual design, and user
experience approaches for these. Testing is then via emulation and
whatever devices we do have on hand between all studio employees. And
then of course hounding our friends with other devices to see results
-- "Hey, nice Kindle . . . do me a favor . . . . " :)
RE: We almost never have the option of being able to take down an
entire domain and build it up how we want.
Yes. This is definitely a luxury. We are currently working on two
projects with legacy systems and are learning how to retroactively
apply the mobile-first (yes, I get the irony) philosophy and
responsive design. It is more challenging that starting from scratch
and definitely takes more brain sweat. And I suspect in the end will
necessitate some compromises around the edges.
Thanks again for the feedback and for all the great information I
learn while just reading the various threads.
Best,
Geoff
Matt Moore
about applying mobile tech to museums:
http://prezi.com/o3t5grbpwfc6/innovationaustmus/
Two points:
- Only a minority of Australians currently use their smartphones to
access the web or download apps (this factoid surprised me).
- Creating a compelling mobile experience (esp. onsite) is not easy.
Here in Australia, mobile access is not ubiquitous or wholly reliable.
From a UX perspective, mobile complicates our understanding of user
experiences. Not all "mobile" experiences are the same. Browsing a
site by tablet on wifi in my living room vs trying to access the same
content on a smartphone on a busy city street (with reasonable 3G
access) vs a peaceful field in the countryside with no data coverage
at all are three very different situations. These three situations
almost certainly require different solutions.
Ensuring that all your stuff (text, database content, images, etc) can
be consumed on mobile devices is handy but designing for mobile seems
to me to be more like dub reggae production - the power is what you
drop from the mix, not about what you can cram in (which would be more
a jazz-rock fusion approach I guess).
But hey, I don't need to worry about mobile. I WAP-enabled my site last week.
Rahel Anne Bailie
- Only a minority of Australians currently use their smartphones to
access the web or download apps (this factoid surprised me).
- Creating a compelling mobile experience (esp. onsite) is not easy.
Here in Australia, mobile access is not ubiquitous or wholly reliable.
Daniel Goddard | London Websites
mobile from 6% in 2010 to 20% in 2011, which for me is the main reason
I'm getting all excited by mobile.
Aaron Burgess
employs me) are, but we're still in the infancy stages because, in
addition to planning for and executing not just a mobile strategy, but
an "ecosystem" (company words, not mine) strategy that scales from
cloud to device to end user and back again, we're heavily, HEAVILY
focused on rebuilding the entire IT infrastructure around our
20,000,000+ page website. So, somewhere in-between all of these
things, we (again, the company, not just the UX team), are working to
reconcile the site with the strategy with the concept that users want
to -- and will -- interact with us across platforms.
The upside to all of this is that thinking of the mobile experience as
an end state has forced us to get back to basic usability principles
as we look ahead to the next few years -- a striking contrast to our
current strategy of building first and planning/organizing after we've
allowed our business owners to dogpile all of their colliding
initiatives onto a platform.
I'm probably not explaining this as well as I could be, but this is
the best I can define the Wild West.
-Aaron
On Sep 3, 9:15 am, Noz Urbina <b.noz.urb...@gmail.com> wrote:
> agreed.
> I heard a recent quote which I should attribute but I can't remember where I
> got it. Someone on this group so they can claim it:
>
> companies should be thinking of content strategies that scale up from mobile
> to desktop, not the other way around.
>
>
>
>
>
>
>
>
>
>
> londonwebsi...@gmail.com> wrote:
> > Put it this way: say you are talking about something and the other
> > person Google's it on their phone. Imagine the difference between
> > having a mobile friendly site as opposed to something that take a few
> > mins to load and you have to zoom x3 and scroll. Which is more likely
> > to convert customers? I'm also staggered about the amount of apathy
> > and complacency when it comes to mobile. It's the future in content
> > strategy and people across the board are, in the majority, almost
> > ignoring it.
> > On 03/09/2011, Noz Urbina <b.noz.urb...@gmail.com> wrote:
> > > I'm staggered this hasn't generated more discussion. This group should
> > be
> > > bursting with people discussing their mobile strategies and
> > accomplishments.
> > > What's up folks?
>
> > > Personally - I've not realised anything either. Lots of clients have it
> > as
> > > a 'roadmap', item, but no one is making it happen.
>
> > > Is that the same for everyone?
>
> > > Any industries leading the charge in particular?
>
> > > On 30 August 2011 00:05, Daniel Goddard | London Websites <
> > >> > Hi all,
> > >> > The company I work for is putting together some FAQ content and much
> > >> > of it has been written by a combination of folks from technical,
> > >> > marketing and business stakeholders. As you can imagine, it's a hodge-
> > >> > podge of approaches.
>
> > >> > Does anyone have any recommendations for articles about writing FAQs
> > >> > that I could share with the content creators to try and get us on the
> > >> > same page? I'd also appreciate it for any tips or suggestions since it
> > >> > appears that I'll be reworking much of that content in the end.
>
> > >> > Thanks,
> > >> > CT
>
>
danetroup
is a good discussion. The native app can do some wonderful things in
the contextual side of mobile and with user experience. If the
interaction is limited to the world of the app and the users that live
there, it is an excellent solution. Words With Friends is a great
app.
The limitations of Native apps are exposed when you begin to try to
share across platforms and devices. The almighty URL. A Uniform (or
Universal) Resource Locator. You cannot open a page in a app from an
email or social media. If there is a link to a page on your site that
is picked up in the blogosphere and when a mobile user tries to access
it they get bounced to a different "m." experience that may not even
have the link, you are losing a lot of traffic. Here is where content
and information needs to have consistency across devices or access
points. When I refer to mobile I am speaking any device that has a
browser and fits in a pants pocket. Bryan and Stephanie at www.yiibu.com
have great reasoning around leaving no one behind and strategy behind
accomplishing it.
How you display the content at the URL is the tricky part. I would
tend to agree with creating for mobile first and rolling the
experience up as technology support is detected (webkit browsers, html
5, css, javascript etc...). Adaptive layouts are gaining in popularity
(http://mediaqueri.es/). Twitter has moved to the #! (hash bang)
approach to content management. Everything is actually achieved on a
single page using AJAX type solutions. This relies on JS so it does
discriminate against millions of users. The point being, if the url
gives every device the same information and ability to share the
information, your job is done.
Luke Wroblewski (who coined the "Mobile First" term) just wrote an
interesting article on why he had separate pages for Mobile and
Desktop with his site Bagcheck.com - http://www.lukew.com/ff/entry.asp?1390.
The interesting thing was that if you shared the like from mobile and
went in from desktop, the app was smart enough to serve up the correct
layout. Bagcheck was also built entirely on an API so it was basically
just doing template swapping. Luke blogged a lot about how Bagcheck
was built and in my opinion it is a great case study.
Mobile is only going to take more time away from PCs. Speed of
networks and devices will become less of an issue and the users
expectations will be quite high.
Best
Dane
Dane Troup
VP Information Architecture
FTIconsulting.com
dane...@yahoo.com
Destry Wion
WHY IS NOBODY TALKING ABOUT THIS?
I think people are talking about it, but it's just not mainstream yet.
And more code wranglers are talking about it than content people at
this point because few content people can do code, which mobile
success relies on just as much. I know smart content people who have
trouble putting class attributes in HTML elements. Until code and
content people start working together more, there's going to be two
sides of the discussion. Coders are simply getting there first.
At CS Forum 11, mobile was recognized as one of the keys for content
strategists to use in getting some content strategy off the ground
where it's been missing or hard to sell. I.e., if you're losing the
"we need CS" fight, then maybe the way in is "we need better
consideration to mobile" (cue the mobile trend statistics) and use
that as the opportunity to build content strategy around it, or at
least in successive steps…small victories.
SEPARATE SITES?
It's a context thing, as ever.
It's no more correct to argue for separate mobile sites than it is to
say every site should be responsive and device agnostic. Luke
Wroblewski has already said very smart things around context of use,
and we would do good to start from what already makes good sense in
that respect.
Context of use (e.g., sitting comfortably on the couch at home, or
dashing from train to train during rush hour), is one thing. Types,
formats, and size are another (pdf, video, code blocks...). And
anybody who knows a bit about localization/translation knows that a
bilingual website isn't just double the work—it's exponentially more
complicated and costly! The same holds true for every separate website/
device/app you support for a single language. It's much more
complicated/expensive to maintain (think long-term UX, then imagine
doing it for multiple languages.)
Single, responsive solutions, whenever possible, will help to reduce
complexity and cost, and make implementing content strategies around
mobile more feasible. Baby steps are the logical way in to CS around
mobile.
Another point that came up again and again at CS Forum is the old
adage "less is more". The less content you have to mess with, the
easier it is to maintain, translate, make device agnostic, etc. It's
going to take a long time, no doubt, but the trend for companies will
be to strip down their content, and thus refine their distribution
channels/tools, not keep building up and out to support the bloat.
Seems there's still a lot of work for people who like doing content
audits. That may yet still be the best single tactic for developing a
CS around mobile. Find out what can be shit-canned first!
I read somewhere not long ago that Microsoft is working in this
direction; has removed thousands of legacy pages of content from their
sites and seeing benefits from it; visitors finding information faster
and sticking around longer. Don't have the reference for that source,
sorry.
EXAMPLES/SHARING
I just rebuilt france.iabc.com and made it fully responsive (my own
site is about to relaunch with full responsiveness too). This is a
small site, but nevertheless some clever things done to handle certain
situations and contexts. For example:
1) If you look at a given upcoming event on a laptop sized screen
you'll see a Weezevent registration form embedded in the article. This
is done through an iframe, but since we can't easily make iframes
flexible, and nor would we want to in this case for the sake of form
usability, the form is hidden at phone sizes and a gold "Register for
event" button appears in the gray event box instead that takes a user
outside of the site to register at Weezevent's site itself. The burden
of form usability, in this case, is put back in the hands of Weezevent
(the form creators) where it belongs. Meanwhile the IABC France site
looks right sharp at every size, and loses none of it's
functionality.
2) Less voodoo-like, but more context-poignant, is the home page. At
full sizes you see the intro box about IABC France. At mobile sizes,
particularly phone, we hide that, because when content linearizes it
sits at top and frankly that's not something you want to read every
time. They can click the About link in the main menu if they want to
get that. Instead, people just get what new events or blog articles
there are.
Text is relatively readable, and most of the thinking there is just
using good conventions of relative units, and targeting a smart ranges
of device sizes. Anyone having read Marcotte's book on responsive
design knows what I'm talking about.
I think little things like this are the level of thinking we can be
doing around mobile right now. Not all CS thinking has to be huge,
monumental, and megalithic. It's going to take a while. Something
Rahel said earlier about adding in class attributes for when the time
comes. That is smart strategy. That is smart CS around mobile at this
point in time; getting ready for the upcoming.
Rahel Anne Bailie
===
Rahel Anne Bailie, Content Strategist / CM Consultant
Intentional Design Inc. www.intentionaldesign.ca
Content strategies for business impact Tel. 604.837.0034 (PT, GMT -8)
Social apps (skype, twitter, etc): rahelab
LinkedIn: www.linkedin.com/in/rahelannebailie
Ann Rockley
I agree totally. It is our job to future proof our content. With the explosion of devices, the device we have today whether it be mobile or tablet may be very different tomorrow.
Ann
roc...@rockley.com |www.rockley.com |www.rockleyblog.com | @arockley
Intelligent Content Conference 2012
Feb. 22-24, 2012 Palm Springs CA
From: content...@googlegroups.com [mailto:content...@googlegroups.com] On Behalf Of Rahel Anne Bailie
Sent: September-09-11 11:08 AM
To: content...@googlegroups.com
Subject: Re: Where are you with mobile?
I like the idea of future-proofing content. On my project, mobile is technically out of scope, but that doesn't stop my team from future-proofing the content for mobile. Because we know that some stakeholder at some point will discover that their Blackberry is good for more than phone calls and email, and then we'll be asked to put mobile in scope. And frankly, I don't want anyone to have to touch those xx,000 pages again to make them mobile-friendly. Or translation-friendly. Or single-source-friendly.
Ann Rockley
statement that "And more code wranglers are talking about it than content
people at this point because few content people can do code, which mobile
the web is about the code or eBooks is about the code. The code is how we
support our content strategy, not a part of the content strategy.
It is true that with each new delivery platform code rears its head because
there aren't effective methods and user interfaces to handle the display of
the content on the platform or device. In the early days of the web, content
contributors had to code themselves or they handed it off to webmaster to
code it for them. But now we have templates and WYSIWYG tools that enable
content contributors to do what they do best, write. This was also the case
with XML (now there are user friendly interfaces to hide the XML) and even
with print before desktop publishing. It is a sign of an immature market
when users/writers are expected to code.
That being said, I agree with Rahel's comment about future proofing our
content. We need to create modular structured content that is responsive to
the environment. When we write modular structured content, we can mix and
match modules, filter out content that is not appropriate on the device or
platform, and layer content in different ways.
No content contributor/content strategist should ever have to code.
I always tell my clients that they may not be doing it now but there is a
good chance they will be in 18 months and do they really want redo all the
work they have done all over again, just to handle another device?
Ann
roc...@rockley.com |www.rockley.com |www.rockleyblog.com | @arockley
Intelligent Content Conference 2012
Feb. 22-24, 2012 Palm Springs CA
-----Original Message-----
From: content...@googlegroups.com
[mailto:content...@googlegroups.com] On Behalf Of Destry Wion
Sent: September-09-11 9:03 AM
To: Content Strategy
Subject: Re: Where are you with mobile?
Just stumbled in. Interesting topic for me.
WHY IS NOBODY TALKING ABOUT THIS?
I think people are talking about it, but it's just not mainstream yet.
And more code wranglers are talking about it than content people at
this point because few content people can do code, which mobile
success relies on just as much. I know smart content people who have
trouble putting class attributes in HTML elements. Until code and
content people start working together more, there's going to be two
sides of the discussion. Coders are simply getting there first.
...
Karen McGrane
There's a lot of talk about Responsive or Adaptive Web Design as a way to take chunks from a desktop site, shove them around and/or shrink them, and make them fit on a mobile handset or tablet. We as content people need to support that by arguing for more modular, structured content—not custom content for mobile, but flexible content they can reuse in different ways.
The development community is out in front of us on this one, because they've been talking way more about responsive design. Well, they're not out in front of Ann, she's WAY ahead of everyone. But I do think mobile is a great wedge issue that helps make clear why we need modular, structured content.
-k
Rich Thompson
It’s just another delivery platform. One that comes with its own bag
of opportunities, constraints and challenges.
We are content strategists, not platform strategists. Maybe because
we’re all geeks at heart (I speak for myself), we are attracted to
technology like moths to a light bulb. But content isn’t technology.
Whether I’m telling you a story, giving you instructions, helping you
accomplish a task or trying to convince you to do something, the
content should sit in a layer above the delivery platform. I could
tell you in person, write you a letter, show you in person, make a
video, write a poem, put it on a sticky-note, etc.
Sure, the content will be adapted to the delivery platform (and take
advantage of whatever benefits the technology offers), but the value
of the content has nothing to do with the technology. And we need to
work with designers and coders to make sure the technology doesn't
hurt the content.
All content strategy projects should start with A) what the
organization is trying to achieve and B) what the user/customer is
trying to achieve. Our job is to create a content experience at the
intersection of these two that enables both parties to come away
satisfied. Delivery platform considerations come later. Our job is to
solve communications problems, not sell technology.
ANECDOTE: Last year I worked on an in-house safety awareness program
for a large construction materials company. The comms people said: we
want to produce posters, a leaflet and web content, but the creative
has to be fantastic because everyone ignores the materials we produce.
Hmm. I dug a little deeper and discovered that most of the safety
problems were occurring in the parts of the workplace where posters
aren’t allowed/aren’t feasible and no one has time to read a leaflet
or has access to the intranet (think vehicles, workshops and
hallways).
We ended up chunking the content into bite-sized pieces. We then
delivered it inside vehicles, on floors and on cubicles partitions
using transparent stickers. Of course, we produced the perfunctory
posters and leaflet, but by understanding the context and the
audience, we were able to find a more suitable delivery platform – one
that was about as low-tech as you can get.
Destry Wion
Loved that anecdote! And I agree 100% with your point about mobile
being another delivery channel, not some special case. But I hope,
speaking for myself, I'm not "obsessing" about it. We talk about
facets of CS—be it audits, mobile channels, or anything else—because
it's relevant and interesting to various degrees and contexts. Or so I
like to think. :)
Anne,
Karen had me right. I'm not saying content people need to be coders
(though I feel they are better off if they can talk the talk, if not
walk the walk). I was referring to the fact more coders are talking
about mobile content than CS people are right now, and they're doing
so rather smartly.
Noz Urbina
This applies exactly to mobile. Although some of my most respected colleagues believe that mobile is often just another way to deliver the same materials, I believe that the context and the medium can and should alter the message. You may want content on the move that you never needed while seated at a workstation or at home (or with your laptop on your knees on your toilet... not that I've ever heard of such thing happening). So, I think we do our users a disservice if we obsess about mobile, but also if we mix up two similar but not interchangeable ideas, specifically:
- They need diagrams that are just two big for phones, and juuuust might work on tablets
- They need to go offline, and need to be able to cache content in an app, synching their changes when they can go online again
- They want to submit multimedia contributions from mobile using the device's camera, which they would never really bothered doing from a desktop.
plumme...@gmail.com
I think we need to take mobile very seriously.
The fact is that the extent to which we use content on say the PC, is way different to the mobile experience.
I remember reading Cameron Moll's offering on coding for mobile in which he argued that coders ( and by extension CS) need to understand that a mobile user may be juggling so much stuff in his/her hand at the same time and therefore, code needed to account for this behavior.
As long as implications like these and the sheer number of users compared to laptop/desktop users are taken into consideration, then it is my belief that any content strategist who does not obsess may lose out in the future.
Sent from my BlackBerry® device from Digicel
Noz Urbina
Lisa Moore
The client conducted user research to understand what it was their customers wanted/needed from a bank in a mobile context. And it should come as no big surprise that people wanted functionality - check a balance, make a transfer, etc. They didn't want - or even expect - to be able to research mortgage products or compare ISAs on their morning commute.
I did research of my own into mobile "best practice" at the time and found those two main themes that have come up in this thread again and again: context and behaviour.
In terms of context, it seems mobile users could be broken down into two broad categories based on where they were when accessing the mobile web:
• On the move – where they were likely to be performing task-, location- and/or time-sensitive actions whilst they're on the go; and
• On the couch (or on the train/bus/commute) – where they were likely to be engaged in a more private, immersive browsing experience, such as watching a movie, IM'ing with friends or reading the news.
In terms of mobile user behavior, Google released findings in 2007 that identified three specific types:
• Repetitive now: checking stock quotes or sports scores;
• Bored now: waiting on a train or killing time between meetings; and
• Urgent now: checking flight departure times or making a last-minute gift purchase.
IMO, those broad brush ways of viewing the mobile experience are still valid.
On a side note, I'm currently working on a large scale web re-design and one of the client's requests was that the new sites (and there are several brand sites under the parent umbrella site) be "viewable on mobile devices".
The client has already selected a CMS that makes it seem as though publishing website content to the mobile channel is as simple as clicking a few buttons. Of course it's not and frankly, I think these CMS products that downplay the complexity of mobile, social media, etc do content and digital strategists a disservice.
In this case, the client is besotted with visions of a multi-channel publishing Utopia and IMO has been lulled into a false sense of complacency by this "out of the box" hype. Dangerous indeed.
It has been suggested to me (by someone much smarter about the CMS world than I am!) that there seems to be a fundamental issue regarding the lack of patterns (or implementation of patterns) when it comes to trying to bridge the gap between CS and the CMS.
I know the folks at Contentini attempted to create a web CS design pattern library. Maybe we need to start thinking of mobile patterns to add to our content strategy pattern language…?
--Lisa
PS: All hail McLuhan, of course, but if you haven't done so already, I encourage everyone to dig into Jan Chipchase's outstanding ethnographic research into mobile usage in emerging markets.
Rich Thompson
Totally agree with all that's been said. My comment about "obsessing"
about mobile comes from my personal experience with clients and
agencies.
I didn't mean to say that would should stop thinking about it. But
cool heads should prevail.
Mobile is a word that gets bandied around too much, just like social
media. There's too much hype (except among us).
My (perhaps simplistic) view is that content needs to adapt to the
context of the user (how, what, where and when). This implies that
there may be some kinds of content that are only available on mobile
devices, while other forms of content are "gracefully degraded" from a
desktop to experience for a mobile experience. It also implies having
a CMS capable of delivering a single-source, publish on anything
model. And this ain't the case today. And it implies having new
content patterns (like Lisa said). Happily, by the looks of it, some
very bright people are working on this.
I found Lisa's side note to be very telling of where clients are
today. Stipulating that content be "viewable on mobile devices" is
simultaneously refreshing and disheartening. While it's great that
they are thinking about content on mobile devices, it's sad to see
that the mobile experience with content is reduced to simply viewing
it. How about using it, understanding it, sharing it?
-Rich
Nathan Blows
--
You received this message because you are subscribed to the Google Groups "Content Strategy" group.
To post to this group, send email to content...@googlegroups.com.
To unsubscribe from this group, send email to contentstrate...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/contentstrategy?hl=en.
Nathan Blows
021 976 4376
084 526 3965
Cliff Tyllick
From: Nathan Blows <natha...@gmail.com>
To: content...@googlegroups.com
Sent: Monday, September 12, 2011 11:35 PM
Subject: Re: Where are you with mobile?
Cliff Tyllick
- here the slides (on SlideShare), and
- here's the associated case study site.
Tomomi Sasaki
--You received this message because you are subscribed to the Google Groups "Content Strategy" group.
To post to this group, send email to content...@googlegroups.com.
To unsubscribe from this group, send email to contentstrate...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/contentstrategy?hl=en.