Lori Bousson

Hello to all!

This will be my last blog for the Preservation Department, not just for 2016, but going forward. Earlier this year, my department (Digital Initiatives,) broke away from the Preservation Department and teamed up with Digital Repository to become a new department, DSI (Digital Scholarship Initiatives.) So… Good-bye old…hello new!

I’ve been thinking a lot about this blog space and how I’ve utilized it during the years that I have been writing for it. Except for one, maybe two posts, they have all been about designing webpages and the challenges I have faced in creating them. I have to say I have learned as much about that process writing down my experiences as I have in creating the actual pages. Someone doesn’t really understand their position until they have to explain it to someone else. I haven’t always been good explaining my job to others, but the act of expressing those challenges on paper has allowed me to also teach myself, and in effect, become more confident of my skills. Sounds weird, but true.

In looking back over my blog posts over the years, I am struck at how constant is change. At one point in my blog writing, I noticed that as soon as I finished writing a blog about Dreamweaver webpage development, I was immediately thrown into developing and transferring our webpages to Drupal. From this constant change process, I have learned that I feel a lot more comfortable designing webpages…even when my comfort level is no longer safe. I mean to say that I have lived in such a constant upheaval environment in regards to designing web pages and the software that we use, over the last few years, that when I am no longer under constant stress of transferring to a new “something”, I feel empty and like: “what do I do know?” But do not worry gentle reader; my new supervisor has taken care of that.  Which is great for me. Instead of treading water, now I feel more in my element than ever before. (When things are flying at me a hundred miles per hour is the only way I feel I am functioning. And besides…times travel so much faster when hands are busy having fun!)

It amazes me that in a span of nine months, what started out as one little site called Digital Collections, way back in the early-mid 2000’s, and was a constant for many years, has morphed and bloomed into a larger site with Digital Collections just one of the sites underneath the umbrella called Digital Initiatives; the last half of the year has found me creating supplemental sites to compliment this new site. Every specialty will have it’s new home (Yearbooks, Online Exhibits, etc.)

But that’s just the future as envisioned in November 2016. Who knows what more changes are in store. All I know for sure is that one must buckle in and get set for a fun-filled bumpy ride into the future. I know I’m going to enjoy it. I hope you have learned as much from reading my blog posts as I have from writing them. It’s been real. Thanks for tagging along with my adventures.


So, lately, I have been working on a new page/site for Digital Initiatives that will eventually become the start page/site for a variety of digital sites under our department. Currently, as you may remember, this is our start page: http://digitalcollections.lib.iastate.edu/. I cannot reveal the new start page, because we are still in the process of creating it. However, I thought I’d focus on one component of the page/site that we have not previously used before: forms.

Now, before Drupal, forms were a pain in keister to create. But now, with a great support staff on hand, forms are super easy to build. Let me show you how.

Forms are a part of Drupal that needs to be “turned on,” in order to work. In our set-up they are turned off to avoid confusion. Also, keep in mind, that once it is turned on, it is available on all pages you create within your site. When it does get turn it on, the magic begins.

I created a Test page to show you how to create a form and how forms work.

It’s very similar to a non-form Drupal edit page, except for the tab just to the right of Edit says Webform.
Let’s click on that.
There are five different sections under the Webform. The first one, form component, is where you add the important parts of the form being created, such as a person’s name, email, address, connection, and comments.

Let’s create a super simple form, which includes person’s name, email, an additional textfield for funnsies, and a comment box.

First, we’ll click inside the “New component name” box, and type Name. The type is Textfield, so we’ll leave that. Now, click on the “Add” button.

Note: this is only a partial screenshot of the page that comes up. Scroll down the age to look over the other boxes you can use to manipulate this info, including making this box a required value. A required value is a value that is needed to proceed. A red star will show up next to the label. Also, on these required fields, I place in parenthesis (required). [I have recently learned that some colorblind users cannot make the distinction between red and black, so adding this helps.] Other fields that are worth looking at: Display. Here you can set the width of the component, add a placeholder in the box (like: myname@abc.com). Also check out the label display. Under this, you can change the label to be displayed above, inline, below the box; description can be displayed above the field; disable the field completely, or make it private, so only users with access can view the results. These preferences can be found on most of the component pages. For now, nothing else is needed, so scroll all the way down and click “Save component” at the bottom.

Let’s add Email now. Label it, “Email,” and change the type to “E-mail,” then tick the “Required” box. Click “Add.”

Oops. I made a mistake. I forgot to label email “Email (required)”. No sweat. Just click on “Edit” beside the Email label, and on the next page, change the title in the label name. Scroll down and click “Save component”.

In the next window, make sure short form is checked for email format, and that “Required” is ticked. You might want to tick “Unique,” under “Validations.” Scroll down to click on “Save component.”

Now, let’s add another textfield.

Here, I’m going to get goofy to show you different things you can do with the form. In this window, check to make sure “Required” is ticked.

I made the Display width 75; I added a Placeholder (to be shown inside field until user starts typing); I Prefixed the textbook with craziness, and Postfixed it with more craziness. Finally, I placed the Label Display to None.

Let’s add the comment box now. Name it “More comments (required)”; choose textarea; make it “Required”; in the next window: make Validation “Required”; and make sure Resizable is ticked under Display; scroll down and click “Save component”.

Here’s what the final super simple form looks like:

Notice that there is no red star anywhere near the “I’m glad” text field. This is something to be aware of, if you decided to hide the label. If any one of those red star areas is left blank, the user will not be able to move forward. OK? OK!

But WAIT! We’re not done yet.

Back under Webform, you can see there is a few more section to the right of Form components: Conditionals, Form validation, E-mails, Form settings. The ones to be most concerned with are E-mails, and Form settings.

Under E-Mails, add the address where you want the comments from the form to be sent to, then click “Add”. In the next page:
Make sure all the email addresses are correct. Custom email/names should be used where you what the emails to go/or what you want the emails to be from called, when the Default email/name is incorrect; E-mail from name should be that address as well. Also check to make sure E-mail header is the right page from where the email are originating. OK. Scroll to bottom, click “Save e-mail setting.”

Let’s move over to Form setting. This page is a doozy, with many options to choose from; my advice: choose wisely, little grasshopper.
First one, most important: I recommend you place a confirmation message in the first box; you have the option of using Full HTML, Filtered HTML, and Plain text. Also, you can add a re-direct page for the confirmation page. Keep the Total submissions at unlimited; make sure Status of this form is ticked for Open. (Closing prohibits further submissions by other users.)

2nd half of page:
These are all self-explanatory. Notice on the bottom under Next submission order. This number should be 1 if you have just created the form; otherwise the number will be whatever number is currently submitted for the form.

One last note: To the right of the Webform tab is a Results tab. This tab shows the results from the form on the page.
Of course, there isn’t much on here right now, but this page will list every form submitted by users, default setting is recently to oldest. Under Operations, will be additional links: View Edit Delete. You can either click on the number under #, or View under Operations corresponding to the number to see the actual submitted form.

Drupal makes it so easy to create and maintain forms. I hope they are as helpful to you as they are for us.

I spend a lot of my time on the internet. It’s a part of my job; usually I’m creating pages, updating, or creating new collections. But lately, I’ve been spending even more time on the web doing research. Our department, Digital Initiatives, has gone through some transitional changes since the first of the year. The biggest one being that we have a new (or, rather: permanent), director: Kim Anderson. She has some cool ideas of how she wants our webpages set up. One idea, that she would like to see incorporated ASAP, is that she wants to have a layer over the top of our current page (http://digitalcollections.lib.iastate.edu/), that directs researchers to either our CONTENTdm boutiques/pages, or to other new pages/collections yet to be implemented. In addition, this main page will have, perhaps, the department’s pertinent information, (or links), as well: staff, tools used, mission statement. That sort of thing.

So, here I have been: looking through and finding similar pages that we may find inspiring for the eventual page layout that we create. I broke it down into two sections, both real-life examples: a “tools” page (which we’d like to create that shows our researchers what we used, both applications wise and equipment wise): and a new “Digital Initiatives” page. Sounds easy enough, right? Well, you know nothing is easy in Lori’s world. Nut .’N. Honey. No, it’s not. I can now understand why Kim wanted to sicced this little gem of a project on me. Not only isn’t there much out there, but as I have been doing this, I have found that, by and large, there really isn’t a “standard” when it comes to describing what we do, and how it’s managed.

It is hard to find separate pages within other academic libraries that demonstrate the importance of this distinction. Since our school is in the Big 12, I’ve looked at all those library sites in search of other Digital Initiatives departments. (Sadly, only schools that made my list where two schools no longer in our league.) I’ve looked at hundreds of “Digital Initiatives” links. In addition, I’ve looked at hundreds of additional general academic library sites. There are only about a good two handful of links that I care to share with our director. Fifteen to be exact. The rest either consolidate it in with another departments, (Digital Repositories; Special Collections; IT;) or don’t even get mentioned at all. And of the ones I have listed, even some of those are a part of these other departments. One university listed their digital collections as a part of their “slides” collections. Sometimes, they have a link to Digital Initiatives and that link sends the researcher to a CONTENTdm collections page. It was just like they were setting these pages up to be a regular library web page. Digital Collections are like exhibit pages. (We call our main collection pages, like: http://digitalcollections.lib.iastate.edu/charles-christopher-parry, boutiques.) I honestly believe that the most innovative digital exhibits are the ones that are easy to navigate; merge well with the items they are showcasing; and make learning fun and informative.

This reminds me of a true work event that I was involved in back in my Tribune days. The paper there had the foresight to see “digital” papers were the coming thing. However, they didn’t have the foresight to involve enough knowledgable persons about the layout of such a site. They didn’t go to one of the composition designers to ask advice. Goodness knows, a designer would have a better understanding of layout. But no…they went to one of their coders who had a general idea of what webpages should look like, and had happened to take one class on web coding at college several years previous. In hindsight, if they noticed this at all, they would have been wiser to have had a collaboration between the coder and a designer. The web pages turned out to look very basic and were very un-intuitive about navigation. Long story short: yeah, email could take you to the webpage for the Tribune, but navigating to pages off the “cover” was a nightmare. The sections navigation made no sense and sometimes one had to jump through several pages to get to the article. I felt sorry for the coder. Person was doing the best they could. But that’s what I thought about when I was researching other library’s Digital Collection pages. I’m starting to see a pattern in my research. It boils down to this: academic libraries seem unsure, themselves, of exactly what Digital Initiatives entail. I’m not talking about the “in the trenches workers” (though there might be some of that too). I’m talking about Administration.

Mostly, this pattern shows a lacking in understanding, and also how poorly forward thinking libraries have become in watching and implementing trends. Our department has been in place for well over eight years. We are modest in development, but the future looks bright for more robust collection developments. I believe we have a very passionate staff that understands digital collections, (although there is always room for growth and enlightenment)!

I know that Digital Initiatives is a merging department. I’m lucky we have a Dean that understand this, and have a passionate director who has cool ideas for not only collections, but our department’s future. I am hopeful that with this new direction that we will not only exhibit digital collections, but that we will innovate and lead the way for Digital Collections departments in other libraries in the future.

Two months ago, I posted in this space about moving the Digital Collection pages over to Drupal. The pages have all been moved over now, and they are live (http://digitalcollections.lib.iastate.edu/.) In this post, I’m going to dive deeper into Drupal and explain one of the things I really like about using Drupal: the Page Tree.  When you use the Page Tree, page names become very easily identifiable. No more: .html pages. Now pages simply end with: [page name here]. The page tree method allows logical, and easy to understand organization. There are a few items to keep in mind, and I’ll explain those as we proceed.

Say you’re on Carver’s page. That URL is:


All subsequent pages associated with carver will end like this:

[carver URL]/biography

[carver URL]/resources

[carver URL]/magazine-and-journal-articles

I could have gone inside the page and drilled down further. For example, I could have had the links on the resources pages link off of the resources page. (Which would look like: /resources/magazine-and-journal-articles, signifying that it was located off the resources page, but I didn’t do that for this site.)

Here is an example of what a page tree looks like:


Notice on the page tree page, there is a list underneath the Tree icon (Home,) and then each little white triangle turns black when you open it, and shows the pages associated with it below. folder2.jpgicons (looks like a folder,) represent actual pages, where the  link2.jpg  icon (looks like a piece of chain,) represents a link. When the selected page is highlighted (here in blue,) the Page Properties are indicated for that page. Notice that the page tree pages/links are in red. Not all page trees have links this color. After the styles were added, these link turned from default black to red. I’ll have to see what happens with the links on the Special Collection as I start to style them.

I really like the Page Properties; it gives a lot of good, self-explanatory information.  Right from this window, you can Change Settings; Make a New page/link (which will become associated with this page;) Edit the page/link; Change Permissions (I strongly recommend NOT doing anything with this, unless directed by the IT department;) View the page/link; Trash the page/link. Let’s click on the Change button.


On Page Properties Change page, you can change the Visibility of the page, Nav Title, and Path. Save or Cancel, when done. Now, I am going to tell you about some things I learned when using the Nav Title/Path boxes. Say you have a title that goes like this: Pascal’s Photos & More. This is what the page tree path will appear as: pascal-s-photos—more. [Ed. Note: it will look like three dashes after photos, not one long dash.] Notice that Drupal takes out the apostrophe and “&” and replaces it with “-“. This is important to remember. It doesn’t mean you can’t have the page title be Pascal’s Photos & More, only that you will need to go into the path and manual change it to pascals-photos-more. You can take out the extra dashes and the path will still work. This is where the Change page of the Page Properties really become useful. The Visibility box is useful as well. Checking it off makes the become “invisible” to the public. You can still “see” the page, when you are logged in, under the Page Tree. And if you have that page linked on other Drupal pages, it will still be linked for use. This comes in handy when you have a lot of pages and you only want some to show when the menu is displayed. Here is an example of an invisible page in the page tree:


The link is grey, and italicized, to indicate invisibility.

OK, let’s click Cancel on the Page Properties page to back up. There is one more feature I will share today in Drupal that is handy in a pinch. (And goodness knows, I’ve been in a pinch once or twice…or, well, never mind.) When logged in to make changes on the Drupal pages, there are few tabs across the top of each page.


View, Edit, Revisions, Permissions, Drafts. Let’s look quickly at Revisions.


What a wonderful feature. A real lifesaver, believe you, me! If you goof-up on a page you can easily go back in time and select the revision you need, whether a minute ago, or last week. This is a nice way to work, and fairly worry free. That makes working with Drupal pretty fool-proof. Which is why so many people are able to use Drupal without much training at all.

So, remember back to May 19 of this year when I began talking about creating templates in Dreamweaver, and again on July 21, when I blogged part two of that series? And also remember how I drone on about technology always changing?

Well…. Throw those two blogs out the window and digest this: I am no longer using Dreamweaver to make our webpages. Our library has moved to Drupal for content-based webpages. And in doing so, I needed to learn it quick. Now, granted, I was given a great deal of leeway as to when to implement this for our pages. I could wait a year. But I had my own agenda. Not only did I need to move Digital Collection pages over, but also Special Collection pages. And I set my timeline to be the end of 2015. Well…why not?

Let me take this blog space to begin talking about Drupal, and my first impressions.

First, the benefit for the library is that more departments are allowed to contribute their own content, instead of having someone from IT doing it, thereby causing a delay in getting the information up to researchers. Because Digital Collections and Special Collections has been creating their own pages for several years now, we were made the testing team to see if we could get this done, and how long it would take. (We meaning: me. I have all but taken over maintaining the Special Collection pages. Brad Kuennen has taken on more responsibilities, leaving most of the fun work to me. Yea ME!)

But back to self-authoring. This is a good thing for a large portion of library departments. Allowing each department to design and implement their pages grants those departments to update their information on the fly and this pretty awesome too.

Plus, to have “templates” in place helps to maintain the overall layout theme of the university. In having a consistent design, every page of the university appears more uniform. Then there is the concept of responsive design. I myself have had issues with this very thing in the past. This is where Drupal comes in and does the heavy lifting. Once you’ve created a page, it automatically makes it responsive. In other words, whether displayed on desktop or mobile device, or tablet, the page will be displayed in the best possible manner. The image(s) will shrink down to the appropriate size and what is called a hamburger will appear (typically in the upper left or right hand corner of the page,) for the drop-down menu.


(This is what a “hamburger” looks like on a sized-down, (read: mobile) responsive page. It squishes a menu down into the three horizontal line icon; when you tap on it, it drops the menu down; again, it usually appears on mobile-designed pages.)

So, what does that mean for designing pages going forward then? Well, a lot of things. First of all, because our library has a great library-external, but on-campus, support from the ITUIS department, I don’t have to worry about consistency across web browsers as I had to in the past. The ITUIS department has worked those issues out with Drupal already. We don’t have to re-invent the wheel here; they follow ISU template guidelines and work from there. Thankfully, because Digital Collections and Special Collections are on a separate server, this allows us to maintain our sites separately, which in turn gives us even greater control over the design and layout of our pages. But what does that really mean? There are differences; let’s take a look.

Here’s our old page on desktop, created in Dreamweaver:


And here’s the new, created in Drupal:


The first obvious difference is the spacing in the vertical menu on the left. Drupal doesn’t allow close spacing (at least on the theme that ISU maintains.) The slider image is wider, but height is narrower; and the dark boxes are no longer as clearly separated (no white line between them.) These images are both pretty similar on tablets; the only difference being that for Drupal, the menu runs a little longer down the side, and the boxes on bottom are clearly separated:


BUT, take a look at the portrait view layout on a tablet.

Old Home (Dreamweaver) on mobile and tablet, portrait view:


(In portrait, you just get a piece of the image, as it is a fixed layout. This is a desktop view of mobile device. An actually mobile device would cut off the top of the second box; but the layout is identical.)

New Home (Drupal) on tablet, portrait view:


(A lot better separation here, plus no cut-off of images.

And New Home (Drupal) on mobile:


The point is Drupal makes designing responsive pages pretty easy. The most intensive part was copy and pasting the pages over from Dreamweaver, and constantly contacting the ITUIS department to get the styles displaying correctly. I’m glad I started with the smaller Digital Collection site however, because when we attempted to make the new pages go live, everything was defaulting to a wrong URL link. First, we thought we were going to need to manually re-mapped all the pages to the new pages, so that old URLs would bounce to the new page URL. Now, ITUIS has stepped in and indicated they will be able to solve this issue using another tool. We will have to monitor this unfolding drama and we will have to think it through for the larger Special Collection pages.

This post is a follow-up to Adventures in Making Templates: Part I.

In previous posts, I’ve discussed the history of our digital webpages, and the issues I had creating my first templates. I also discussed how to create an initial template page. Now, let’s turn to creating a new page using a template and additional points to keep in mind. To create a new page using a template:

  1. Open Dreamweaver, if not already opened. [I use Dreamweaver CS6.]
  1. To create a page from a template: File—>New… —>Select Page From Template, then navigate to the template page you created.


Click Create button.

You will notice all your “locked in” code — code that will stay consistent on all pages — is grayed out. You will not be able to edit this area at all on this page. Go on. Try it. Select a section and try to delete it. Can’t. Be. Done. You can select it; but you can’t edit it in any way. However, the areas that are shown in blue or black text are editable areas. So, at the top, you see where I can change my meta content and name, plus page title.


You also have to be aware that not all areas are obvious as being editable. This is where you need to be aware of your code.

This whole area marked in gray (highlighted here, with text below image) is actually editable space:


<!– InstanceBeginEditable name=”additional styles go here” –>


<!–<link rel=”stylesheet” type=”text/css” href=”../cdm/css/reset.css”>–>


<!–additional style types go here–>


<!–additional css links go here–>


<!– InstanceEndEditable –>


Below is an example of code that I placed inside one of these areas:


Notice that you can put css code, javascript; and css links within this area. This is nice to have, because some pages need additional coding that allows for variances on theme. (As I mentioned in Part I: some of our pages have elements that are unique to each page.)

Further on down the page is the space for the inside content, followed by the non-editable footer.


It’s pretty easy to go from there. Once you have the page created, save with the actual name you plan to use and you’re set!

Here’s a comparison between our old (non-template) page on the left, and new page (created with template) on the right:


As you can see, there are subtle differences between the old and new pages. Here’s another example of a longer page:


One of my main issues without using a template was the variety of space between the end of text and the footer. This was a browser issues: some browsers played nice, and others didn’t. Using a template took this issue away. Our pages are now consistent whatever browser one chooses.  Having the template also made it easier for me to add elements that were lacking on every page, like the social media icons.

Templates are great when you have several pages to maintain that all have the same basic layout. They are not for all sites/layouts, but work well for web masters who have many pages with certain elements that need regular updates. I’ve had templates on my radar since I first started working on my pages. I am glad I finally learned how to create them. You may find them useful too.

So, to recap to my previous adventure: I had just learned how to make sticky footers that worked with our pages. I maintain many pages (34, plus a home page) for our website, and they are not all the same length. We have boutique pages. We have thumbnail pages. We have boutique pages with a little image vs. big image at the top. We have thumbnail pages that are short vs. ones that are long. We have a page that has secret embedded code so if you know the super-secret key combination, an elephant will appear in a pink tutu and dance a jig. (OK, well, maybe we don’t have that last one… but wouldn’t it be fun?) The thing is, we have a lot of pages that all basically have the same wraparound: the header, the menu, the footer is all the same. It’s the “inside,” and the length of the inside that’s different from page to page.

But let me step back a moment and give you some history. Here is what our pages looked like a few months ago:


You can see we had a vertical header across the top, along with a vertical menu. Then on the left side, we had a horizontal menu, with links that go to our pages within the site. The footer followed below, with social media icons below that and to the right. The primary reason I wanted to move to templates is that updating 34+ pages individually can be overwhelming at times, even if all you’re doing is copying and pasting. I thought knowing how to create templates might make it easier to maintain the pages.

I got my first chance when I was working on re-designing the Special Collections web pages; all their pages are template-centric. I thought it should be pretty easy to figure out. It would be how I usually figure things out: a combination of Firebug and reserve engineering; but digging through code, I had an issue with wrapping my brain around how to write the thing. That was frustrating!

I went back to my old standby of research; studying; reading. Looking at a made template can be quite confusing. It doesn’t seem logical that it could work. And indeed, my first few attempts were ugly. I’m even embarrassed to say that I might have accidentally messed up the main Special Collections’ old template in trying to figure out how to get the templates to create correct layouts.

One Friday afternoon, I was so frustrated, that I decided to leave work early and have some “me” days. My son, Ian, and I just bummed around all afternoon, had take-out chinese food, (my fortune was: “Now is a good time to finish up old business,”) and I just generally acted juvenile all weekend. That made all the difference in the world. When I got to work, I pulled out the fortune, placed it right beside my monitor and wrote the code for my first template. (Just goes to show, “me” days can be worth their weight in gold.) Here are the things I learned with that first template I created:

  1. Open Dreamweaver, if not open already. I use Dreamweaver CS6.
  1. Create and design a html page: File—>New…—>Blank Template. Select HTML template. I just selected <none> for Layout style, but the choice is up to you.


Click Create button.

This is what a blank DW template doc looks like.


  1. There are certain areas that you will want to leave blank in order for you to change for each page you are creating. For example the name: Don’t change that. Keep in mind, that everything “inside” the

<!– TemplateBeginEditable name=”doctitle” –>

<!– TemplateEndEditable –>

will stay editable. Everything outside of that section will be locked into the template. So, everything that you want to stay the same in every document MUST BE OUTSIDE THE GREEN <!— Template…Editable  —> sections. I cannot stress this enough. This is a very important point to remember.

  1. Add additional <!— Template…Editable —> sections as needed. Don’t be shy creating these sections, but don’t go cray cray either. I added one for additional styles and another one for my inside details, and third one for stat counter code at the bottom of the page. (I used the auto generated head section for my Google Analytics stats, but I also keep stats through StatCounter, and that requires different code for each page.) So, I created three additional <!— Template…Editable —> sections. The ones I listed are probably the most you really need to add. Remember, you only need these sections for code/html that you want to be able to change individually on pages, not universally.

From this point on, just create the page like you would create a normal html page, with css documents; javascript; and html.

When you go to name your template page, use a name that anyone can clearly understand. I named mine boutiquePage. The page will save with a .dwt. This is the page you will open up and edit when you want universal changes across all your template-based pages.

For example, if you have a menu that needs updating, open up this document and make the changes here; once you have saved the document, a dialog box will appear:


Click Update button.

Another dialog box will pop up and give you an update.


Click Done or Close button (which ever one applies,) to dismiss the dialog box. Old documents tied to this template (and new ones created after,) will now contain this update.

If you go into a document connected to the template, you can see (via the greyed out text,) that the information has been updated:


Further, you can check in Preview to see the live view:


Once you have made the change to the template, and saved/updated the other documents, you will need to upload all affected pages again to your server.

We’ll explore making new documents and changing certain elements with those new documents for my next blog, slated for July 21, 2015. Until then, happy coding, and may HTML forever be in your favor.

Next Page »