Deciding whether to use a "Show n items per page" control

7 Dec 2009 - 8:05am
4 years ago
18 replies
837 reads
Jeff Kraemer
2009

Hi all,

How do you decide whether to include a means to control how many list
items to display?

In an earlier thread (http://www.ixda.org/discuss.php?post=46070),
someone pointed to 37Signals' "Getting Real," in which they
suggest that preferences like these are a cop-out, a little decision
that one shouldn't force on the user. Jut simplify and choose a
smart default.

And in a recent round-up of best practices in search results
(http://www.smashingmagazine.com/2009/09/28/search-results-design-best-practices-and-design-patterns/),
it seems to me that most of the example sites the author points to do
not use this UI control. Yet the author calls the use of this control
a best practice.

So, how do you decide whether to include it? Do you follow a general
principle (give the user more control/take away little decisions), or
do you decide based on the users' needs in a given project? And if
so, how do you define those needs?

Comments

7 Dec 2009 - 8:38am
David Lambert
2009

Or, you could go another direction altogether and eliminate paging
entirely:

http://blog.wekeroad.com/2009/11/27/paging-records-sucks--use-jquery-to-scroll-just-in-time

Admittedly, this wouldn't work under all circumstances, but it's an
interesting alternative.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=47813

7 Dec 2009 - 10:45am
Matt Nish-Lapidus
2007

I tend to think that the # items per page control is pretty useless.

I did some testing with it for a product a couple years ago and found
that it was more important to get the default page size right than to
have the option available. For that product we found the sweet spot
was 16 items/page.

A couple other things to consider:

- One control that is a little more useful is the "show all"
option, but that only works if you're dealing with small data sets.

- We had more success with have an expanded and collapsed view
option. The collapsed view would show more items per page, and people
liked this option in testing. They were okay with the choice between
more detail or more items.

Hope that helps!

Matt.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=47813

7 Dec 2009 - 11:13am
bminihan
2007

We had this control front and center in my current project, but after
discussions and brief sessions with actual users, found they didn't use it
that often, and it was implemented so badly that it affected our portal
performance. So I changed the way it works, moved it to the bottom of the
page, and selected a larger default page size. The combination of the two
improved the experience tremendously (page loads in less than five seconds
where it used to take 30-60) and the larger default page size works better
for most folks. Now, only the "power users" who need the whole table (or
just more data) use that control, while it's no longer in the way of the
main experience.

I'd say use it if you have to (or can't afford a continuous paging ajax
control), but select a smart default so that people don't have to use it.

Bryan Minihan

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Jeff
Kraemer
Sent: Monday, December 07, 2009 5:06 AM
To: discuss at ixda.org
Subject: [IxDA Discuss] Deciding whether to use a \"Show n items per page\"
control

Hi all,

How do you decide whether to include a means to control how many list
items to display?

In an earlier thread (http://www.ixda.org/discuss.php?post=46070),
someone pointed to 37Signals' "Getting Real," in which they
suggest that preferences like these are a cop-out, a little decision
that one shouldn't force on the user. Jut simplify and choose a
smart default.

And in a recent round-up of best practices in search results
(http://www.smashingmagazine.com/2009/09/28/search-results-design-best-pract
ices-and-design-patterns/),
it seems to me that most of the example sites the author points to do
not use this UI control. Yet the author calls the use of this control
a best practice.

So, how do you decide whether to include it? Do you follow a general
principle (give the user more control/take away little decisions), or
do you decide based on the users' needs in a given project? And if
so, how do you define those needs?
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help

7 Dec 2009 - 8:50am
Mike Starr
2009

I've not had occasion to make this decision on the development side
but from my own user perspective I really dislike sites that present
a minuscule amount of results with no mechanism for increasing that
quantity. I think many sites do that in order to increase the number
of ad views... the greater the number of ad views, the more potential
revenue from click-throughs.

Yahoo and Google allow users to configure their default number of
search results (I set mine to the maximum of 100) and that number is
saved in a cookie and referenced when the user is signed in to the
site. The downside of that approach is that a user must be signed in
to the site in order for that configuration decision to be active.
Many users object to that from a privacy perspective.

Having a session-based cookie can work as well but some sites that
implement these controls do so only for each search query... do a new
search query and the results page comes up with the default number of
responses and the control set back to the minimum number of
responses.

Of course, if the results incorporate a graphic for each result
listed, a greater number of results yields a longer time to
completion of the page load, so it's a tradeoff. A popular site may
run into bandwidth limitations from its hosting company and possibly
high bandwidth surcharges.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=47813

7 Dec 2009 - 9:28am
Chris Rink
2009

I agree with 37 Signals that you should just choose the paging size.
The page size is really a question of performance. And I don't think
you would ask your user what type of performance they want. You
already know, they want it fast.

That leads to the next question of what you should the paging size be
set to? You should set a page load time and a page update goal and
then test out different sizes to meet your goal. I would error on the
size of faster as when you get to live data, your needs could vary.
This also would reflect if this is a search or a list and if you can
cache anything or not.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=47813

7 Dec 2009 - 12:47pm
Nasir Barday
2006

At the end of the day, the approaches listed here are part of our toolbox
that we choose appropriately, based on the context.

But regardless of the approach, we agree that you need to find the right
chunk size to start with. How many results are enough before someone is
satisfied that they've exhausted what is available? How much is too much
before people's eyes start glazing over? The number will be different based
on the type of information and the nature of the search. For certain
searches in the financial space, for example, people flip quickly through
the first chunk of results and quickly go back to revise their search
several times.

The "endless scroll" works in some cases, but I find it gives an unsettling
"where's the bottom??" feeling, because the scroll thumb, which used to be a
good gauge of how much is left before you're "done" scanning a view, becomes
useless. Get to what you thought was the end, and it turns out there's a
whole lot more.

- N

7 Dec 2009 - 3:04pm
Jayson Elliot
2008

Agreed, the idea of asking users to customize any level of their online
experience generally meets with limited usage. I'm not a fan of user
customization as a general rule, even in desktop applications, unless it's
for specialized use cases such as professionals rearranging their preferred
tools in an application they use for work every day.

In most cases, the presence of customization options is an indication that
the designers couldn't decide on an optimal solution and punted.

I would caution STRONGLY against the "bottomless scroll," however. Bing.com
has been using it in their image search, presumably as one way to
differentiate themselves from Google.

It's been a usability disaster.

The page draws dynamically, making it difficult for a user to develop any
spatial memory of the images they have found. As the user scrolls, they
encounter a behavior they were not expecting from a scroll bar, and the
ability to intuitively understand where one is in the results set is removed
by the lack of location cues.

Once a user leaves the page, they cannot return to their selection on the
page via use of the back button. If they scrolled through several "pages" of
images, they will come back to find themselves looking at different images
than when they left (after waiting several seconds for the page to redraw).

Microsoft has attempted to counter this by opening links in new windows, but
this only leads to a proliferation of windows or tabs that the user may not
easily navigate, or even want.

There may be ways to improve the paging experience, but the "bottomless
scroll" seems like an engineering solution that went in search of a problem.

On Mon, Dec 7, 2009 at 12:38 AM, dlambert <dlambert at appdev.info> wrote:

> Or, you could go another direction altogether and eliminate paging
> entirely:
>
>
> http://blog.wekeroad.com/2009/11/27/paging-records-sucks--use-jquery-to-scroll-just-in-time
>
> Admittedly, this wouldn't work under all circumstances, but it's an
> interesting alternative.
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=47813
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

7 Dec 2009 - 3:19pm
Laura Klein
2009

The one argument I would make to the "pick one optimal size" theory
is that, in some cases, there is no optimal size. One company where I
worked had a catalog of millions of products with images.

Because there were so many products to choose from, users tended to
want to see as many results on a page as they could without slowing
things down too much. The biggest problem for us was the huge
variation in computer quality and connection speed, which made the
pages load at wildly different speeds for different customers. What
would be sub-second response for a user with a new computer and DSL
could take several seconds for someone with an old computer on dial
up.

For some reason, our user base had a pretty significant contingent of
people at both ends of the range, so it was tough for us to pick an
optimal size for the pages. We offered several different page sizes,
remembered the users' preferences, and let people decide for
themselves what their computer and connection could handle.

Of course, products that have different types of customers don't
necessarily have this problem, so it might be best in those cases to
not clutter up the page with extra choices that their customers
don't need. It's all about understanding the actual needs of your
particular users, right?

Laura Klein

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=47813

7 Dec 2009 - 3:19pm
Sharon Greenfield5
2008

Come back?
Honestly, have you ever had a need to go back to images after you've
google/binged them?
Can you imagine a use case scenario?

On Dec 7, 2009, at 12:04 PM, Jayson Elliot wrote:
> I would caution STRONGLY against the "bottomless scroll," however.
> Bing.com
> has been using it in their image search, presumably as one way to
> differentiate themselves from Google.
>
> It's been a usability disaster.
>
> The page draws dynamically, making it difficult for a user to
> develop any
> spatial memory of the images they have found. As the user scrolls,
> they
> encounter a behavior they were not expecting from a scroll bar, and
> the
> ability to intuitively understand where one is in the results set is
> removed
> by the lack of location cues.
>
> Once a user leaves the page, they cannot return to their selection
> on the
> page via use of the back button. If they scrolled through several
> "pages" of
> images, they will come back to find themselves looking at different
> images
> than when they left (after waiting several seconds for the page to
> redraw).

7 Dec 2009 - 3:22pm
Scott McDaniel
2007

Yes.

On Mon, Dec 7, 2009 at 3:19 PM, live <human.factor.one at gmail.com> wrote:
> Come back?
> Honestly, have you ever had a need to go back to images after you've
> google/binged them?
> Can you imagine a use case scenario?
>
>
> On Dec 7, 2009, at 12:04 PM, Jayson Elliot wrote:
>>
>> I would caution STRONGLY against the "bottomless scroll," however.
>> Bing.com
>> has been using it in their image search, presumably as one way to
>> differentiate themselves from Google.
>>
>> It's been a usability disaster.
>>
>> The page draws dynamically, making it difficult for a user to develop any
>> spatial memory of the images they have found. As the user scrolls, they
>> encounter a behavior they were not expecting from a scroll bar, and the
>> ability to intuitively understand where one is in the results set is
>> removed
>> by the lack of location cues.
>>
>> Once a user leaves the page, they cannot return to their selection on the
>> page via use of the back button. If they scrolled through several "pages"
>> of
>> images, they will come back to find themselves looking at different images
>> than when they left (after waiting several seconds for the page to
>> redraw).
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

--
"You always have the carny connection." - Clair High

7 Dec 2009 - 3:24pm
Jayson Elliot
2008

Speaking anecdotally, I would say I come back to the images results page
about 90% of the time.

Some of the ways I use Google Images is when looking for a company logo for
a presentation, album artwork for my MP3 library, book art for my Delicious
Library database, etc.
In all of those cases, I often go to a search result and discover that the
image, once viewed full size, does not meet my needs, and I need to return
to the search results in the same place that I left.

On Mon, Dec 7, 2009 at 3:19 PM, live <human.factor.one at gmail.com> wrote:

> Come back?
> Honestly, have you ever had a need to go back to images after you've
> google/binged them?
> Can you imagine a use case scenario?
>
>
>
> On Dec 7, 2009, at 12:04 PM, Jayson Elliot wrote:
>
>> I would caution STRONGLY against the "bottomless scroll," however.
>> Bing.com
>> has been using it in their image search, presumably as one way to
>> differentiate themselves from Google.
>>
>> It's been a usability disaster.
>>
>> The page draws dynamically, making it difficult for a user to develop any
>> spatial memory of the images they have found. As the user scrolls, they
>> encounter a behavior they were not expecting from a scroll bar, and the
>> ability to intuitively understand where one is in the results set is
>> removed
>> by the lack of location cues.
>>
>> Once a user leaves the page, they cannot return to their selection on the
>> page via use of the back button. If they scrolled through several "pages"
>> of
>> images, they will come back to find themselves looking at different images
>> than when they left (after waiting several seconds for the page to
>> redraw).
>>
>
>

7 Dec 2009 - 3:35pm
Sharon Greenfield5
2008

You don't lose your place in Bing images.
Try it.
Search for something, scroll for awhile, click on it. Not good? Click
back link. Still in search spot.

On Dec 7, 2009, at 12:24 PM, Jayson Elliot wrote:

> Speaking anecdotally, I would say I come back to the images results
> page about 90% of the time.
>
> Some of the ways I use Google Images is when looking for a company
> logo for a presentation, album artwork for my MP3 library, book art
> for my Delicious Library database, etc.
> In all of those cases, I often go to a search result and discover
> that the image, once viewed full size, does not meet my needs, and I
> need to return to the search results in the same place that I left.
>
> On Mon, Dec 7, 2009 at 3:19 PM, live <human.factor.one at gmail.com>
> wrote:
> Come back?
> Honestly, have you ever had a need to go back to images after you've
> google/binged them?
> Can you imagine a use case scenario?
>
>
>
> On Dec 7, 2009, at 12:04 PM, Jayson Elliot wrote:
> I would caution STRONGLY against the "bottomless scroll," however.
> Bing.com
> has been using it in their image search, presumably as one way to
> differentiate themselves from Google.
>
> It's been a usability disaster.
>
> The page draws dynamically, making it difficult for a user to
> develop any
> spatial memory of the images they have found. As the user scrolls,
> they
> encounter a behavior they were not expecting from a scroll bar, and
> the
> ability to intuitively understand where one is in the results set is
> removed
> by the lack of location cues.
>
> Once a user leaves the page, they cannot return to their selection
> on the
> page via use of the back button. If they scrolled through several
> "pages" of
> images, they will come back to find themselves looking at different
> images
> than when they left (after waiting several seconds for the page to
> redraw).
>
>

7 Dec 2009 - 3:48pm
sylvania
2005

> Honestly, have you ever had a need to go back to images after you've google/binged them?
> Can you imagine a use case scenario?

I often go back to a specific page in Google image results. Here's my most common use (anecdotally):

I'm usually looking for an example to use as a reference to help visualise an object while creating an icon or other art. I see a pretty good photo on page 5, but the perspective is a bit off. I keep looking, and see another photo on page 12 with a better perspective, but the lighting is horrible, making some important lines difficult to make out. I keep looking for a while, but not finding anything better after n pages, I decide that the photo on page 5 was a good enough reference. Without pagination, finding that photo again would be a real pain.

Other use cases I've had:
- Looking for a company logo; can't find a "perfect" version, but back on page 9 there was one that was good enough.
- Looking for a certain image, and there it is. Browser crashed, and I didn't have time to copy it. Restart browser, I remember it was on results page 21 of my search.

Cheers,
Sylvania
User Experience Designer

7 Dec 2009 - 4:18pm
Jayson Elliot
2008

I think you're missing an important point.

Clicking on the image in Bing does open the site within a frame, but not the
full image. If you use the "back" button in your browser, you will be taken
to a different place than you were previously.

If you click the "back" link on the page (not using the browser button, as
would be standard), you may be taken to the place you were before, although
the images may have shifted by a row or more.
If you were to click the "full size" link before going back, you will be
taken to a completely different part of the image results.

Full size links open in new windows, which can lead to user confusion due to
loss of window focus.

Overall, it's a clumsy solution to a problem that may or may not have
existed in the first place.

On Mon, Dec 7, 2009 at 3:35 PM, live <human.factor.one at gmail.com> wrote:

> You don't lose your place in Bing images.
> Try it.
> Search for something, scroll for awhile, click on it. Not good? Click back
> link. Still in search spot.
>
> On Dec 7, 2009, at 12:24 PM, Jayson Elliot wrote:
>
> Speaking anecdotally, I would say I come back to the images results page
> about 90% of the time.
>
> Some of the ways I use Google Images is when looking for a company logo for
> a presentation, album artwork for my MP3 library, book art for my Delicious
> Library database, etc.
> In all of those cases, I often go to a search result and discover that the
> image, once viewed full size, does not meet my needs, and I need to return
> to the search results in the same place that I left.
>
> On Mon, Dec 7, 2009 at 3:19 PM, live <human.factor.one at gmail.com> wrote:
>
>> Come back?
>> Honestly, have you ever had a need to go back to images after you've
>> google/binged them?
>> Can you imagine a use case scenario?
>>
>>
>>
>> On Dec 7, 2009, at 12:04 PM, Jayson Elliot wrote:
>>
>>> I would caution STRONGLY against the "bottomless scroll," however.
>>> Bing.com
>>> has been using it in their image search, presumably as one way to
>>> differentiate themselves from Google.
>>>
>>> It's been a usability disaster.
>>>
>>> The page draws dynamically, making it difficult for a user to develop any
>>> spatial memory of the images they have found. As the user scrolls, they
>>> encounter a behavior they were not expecting from a scroll bar, and the
>>> ability to intuitively understand where one is in the results set is
>>> removed
>>> by the lack of location cues.
>>>
>>> Once a user leaves the page, they cannot return to their selection on the
>>> page via use of the back button. If they scrolled through several "pages"
>>> of
>>> images, they will come back to find themselves looking at different
>>> images
>>> than when they left (after waiting several seconds for the page to
>>> redraw).
>>>
>>
>>
>
>

8 Dec 2009 - 10:58am
Anonymous

Part of it depends on what your users want. When I was working on a site
search project, the general range of results people expected were either 10
or 20. More than 20 was overkill, less than 10 didn't give them much
confidence that they'd seen a good snapshot of what was in the results. We
offered a "how many items" option and the majority of our users tested said
it was nice to have but they probably wouldn't use it.

Part of it depends on the use of the list. We were acutely aware that users
rarely move past the 1st page of search results unless they think they're
close to the results they want, so we chose 10 results because we were
confident our top 10 results generally had what they wanted. (If we'd've
had less confidence we'd've gone with 20. We didn't have enough confidence
to go with 5 results.) But for shopping or browsing a category, different
mental paradigms are in play.

Part of it depends on both your technology and your users' technology. If
your server chokes when you serve more than 10 items, don't offer a choice
higher than 10. If your server can handle as much load as you want to give
it, but your users are all on dial-up, don't serve more than the number of
items that dial-up can handle in a timely manner. If you've got a split
audience (some slow connections, some fast), offer choices so those on a
fast connection can see more items if they want to.

anne gibson

new-bounces at ixda.org wrote on 12/07/2009 12:05:44 AM:

> Hi all,

> How do you decide whether to include a means to control how many list
> items to display?

----------------------------------------------------------------------
CONFIDENTIALITY STATEMENT. The information contained in this e-mail message, including attachments, is the confidential information of, and/or is the property of, Vanguard. The information is intended for use solely by the individual or entity named in the message. If you are not an intended recipient or you received this in error, then any review, printing, copying, or distribution of any such information is prohibited, and please notify the sender immediately by reply e-mail and then delete this e-mail from your system.

8 Dec 2009 - 11:42am
Jayson Elliot
2008

Your point about users needing to "think they're close to the results they
want" is a very good one, as it speaks directly to the need for a strong
scent of information.

One way to provide this might be to display the results in a style similar
to the Apple TV or Front Row interface, where additional items are shown
"peeking in" from off-screen. That would encourage users to keep paging, and
provide a visual cue that additional pages are available.

On another note, I would be careful asking users what they want - I notice
that you said of one feature " the majority of our users tested said
it was nice to have but they probably wouldn't use it." It is notoriously
difficult for users to predict their own future behavior. It is better to
rely on observed behavior than reported preferences.

On Tue, Dec 8, 2009 at 10:58 AM, <anne_gibson at vanguard.com> wrote:

> Part of it depends on what your users want. When I was working on a site
> search project, the general range of results people expected were either 10
> or 20. More than 20 was overkill, less than 10 didn't give them much
> confidence that they'd seen a good snapshot of what was in the results. We
> offered a "how many items" option and the majority of our users tested said
> it was nice to have but they probably wouldn't use it.
>
> Part of it depends on the use of the list. We were acutely aware that users
> rarely move past the 1st page of search results unless they think they're
> close to the results they want, so we chose 10 results because we were
> confident our top 10 results generally had what they wanted. (If we'd've
> had less confidence we'd've gone with 20. We didn't have enough confidence
> to go with 5 results.) But for shopping or browsing a category, different
> mental paradigms are in play.
>
>

11 Dec 2009 - 6:31pm
Jared M. Spool
2003

On Dec 7, 2009, at 8:05 AM, Jeff Kraemer wrote:

> How do you decide whether to include a means to control how many list
> items to display?
>
> So, how do you decide whether to include it? Do you follow a general
> principle (give the user more control/take away little decisions), or
> do you decide based on the users' needs in a given project? And if
> so, how do you define those needs?

Jeff,

I'd like to suggest that the reason you're struggling with the right
answer (and why nobody who responded really had a concrete solution)
is that you're possibly asking the wrong question.

I'd like to suggest that users don't care how many items they see.
They only care about seeing the right items.

Choosing an item from a large collection involves a three-step
process: winnowing, selecting, and validating.

Winnowing happens before you present the list. It's the process of
choosing filters and specifying what the user doesn't want to see. If
you winnow the choices properly, every choice you present to the user
is a high-quality, likely candidate.

Selecting happens during the list. Here the user is comparing one
choice to another, and picking the one that best fits their needs.

Validating happens when the user has made their choice, giving them a
single result where they can ensure they've made the right choice.

So, how many items should you display? All of the best, most-likely
choices and none of the rest.

The important factor is to ensure you're giving enough information to
select. What's enough information? That'll depend on what you're
displaying in the list and how you display it. The trick is you want
to prevent the user from clicking to find out if the item is what they
want. They should know before they click. (If they click before
knowing, that's likely to lead to pogosticking, which is very
undesirable as it almost always leads to task failure.)

Because you want to have enough room to show the important
information, you also want make sure you've eliminated any choices
that are unlikely. That's where good winnowing comes in. Giving the
user a good set of controls to choose the subset of choices that will
most likely satisfy their needs is an essential quality of a good
experience with lists.

If you do all that, you won't need control to choose the number of
list items displayed. The winnowing will reduce the number to a
manageable set that you'll want to present in its entirety for the
user to select from.

You can read more about this here:

Galleries: The Hardest Working Pages on Your Site
http://www.uie.com/articles/galleries/

I hope that helps,

Jared

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool at uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks Twitter: @jmspool

15 Dec 2009 - 12:50am
cfmdesigns
2004

On Dec 7, 2009, at 6:28 AM, Chris Rink wrote:

> I agree with 37 Signals that you should just choose the paging size.
> The page size is really a question of performance. And I don't think
> you would ask your user what type of performance they want. You
> already know, they want it fast.

I would think that rather than making the user choose one or choosing
one that may be fine for most and lousy for some, better would be let
the user's environment determine the size. That is, whatever portion
of the window isn't occupied by header and footer and overhead, that's
determines how many items show. If they change the window size or
possibly the text size -- which indicates a desire to change how they
view things, you change how much shows to match

-- Jim

Syndicate content Get the feed