What Matters Most During a SharePoint Migration?


You may also be interested in: SharePoint Conference.ORG 2013


 

Editor’s note: Contributor Sean O’Leary is the Senior Manager of Global Communications for Metalogix Software. Follow him @metalogix

To say there is a lot involved with a SharePoint migration is to put it extremely mildly. There are hundreds of potential pitfalls along with hundreds of options for how and when you set forth on a migration project. It can be overwhelming.

But when you are preparing to undertake a SharePoint migration, whether you are upgrading from an older version or consolidating file share content into SharePoint, what really matters? What are the key things you need to be successful?

How to effectively migrate SharePoint has always been a hot topic within the SharePoint community and its urgency has only been increased with SharePoint 2013 looming in the distance. At both the SharePoint Conference 2012 in Las Vegas and the European SharePoint Conference 2013 in Copenhagen, we received many questions, concerns and comments about the topic.

It was why we wanted to get an accurate gauge of what the community was thinking as we conducted the SharePoint Content Survey. We posed a simple, yet critical question with an option to select more than 1 answer to more than 100 SharePoint and IT professionals, spread between the public and private sector:

2013-03-19-SP2013Migration-01.png

The fact that high-fidelity, including maintaining metadata, permissions and versioning information, clearly speaks to the maturation of SharePoint. All of the respondents in the survey were running SharePoint, with 40% still running at least one SharePoint 2003 or SharePoint 2007 farm. The survey also revealed that 60% want to move to SharePoint 2013 within the next year. It is a reasonable assumption that high-fidelity is so important because there is so much information within current SharePoint environments, that losing any of it is simply unacceptable.

The next most popular responses – pre-migration planning – links back to the ultimate goal of completing migration projects effectively and efficiently. As we discussed in our recent SharePoint 2013 webinar, there is no substitute for planning when it comes to a SharePoint migration. Without a proper inventory in place and a complete plan, your project is doomed from the start.

The last 2 responses go hand-in-hand and mark a shift in the mindset of the SharePoint professional. When SharePoint farms were being measured in GBs, the need for speed was less of a concern because even a slow migration, whether with out-of-the-box tools or another third-party tool, would not take too long. But moving 250GBs is a whole different ballgame than moving terabyte upon terabyte of content.

The no downtime migration speaks, again, to how SharePoint has become business-critical. Imagine trying to tell your organization, which is now relying on SharePoint every single day for collaboration, that it will be down for several days. The odds that it would be received favorably are remote, and that’s putting it kindly. SharePoint simply cannot be down, for any reason, during a migration.

The speed aspect becoming more prevalent is to be expected and, if this survey were conducted in November 2013, would continue to climb in the minds of SharePoint admins and IT directors. As content continues to grow at an extraordinary pace, so does the amount of content that needs to be moved during any SharePoint migration and upgrade. The quicker that content can be moved means a quicker project for you – and the speed of business is not going to slow down for your project.

Mega Menus for SharePoint – Part 2 of 3


You may also be interested in: SharePoint Portals in minutes by SharePoint Implemented


 

Editor’s note: Follow contributors Heather Solomon and Dustin Miller @spexperience

This is the second part of a three part series where Heather Solomon and Dustin Miller are exploring the ever-popular "Mega Menu", and how to create a powerful, styled and functional mega menu for use on your SharePoint sites. After creating the HTML markup and the CSS to meet the functional requirements, it is time to take a look at the importance of taxonomy in navigation and check out the XSL that will be used for the mega menu.

2013-03-22-MegaMenu-Part01-01.png

Taxonomy and Web Site Navigation

Heya! Heather here and one thing I hold near and dear to my heart is web site taxonomy and usability. It is an often overlooked aspect of web site development when a project gets kick started. Be it budget, time or lack of priority, site taxonomy (and by association content requirements) is usually brushed aside, done in a hurry or just flat out kicked to the curb. It is hands down one of the biggest mistakes I see organizations make when they start a web project.

It shouldn’t be this hard

If you are ever feel the urge to read a bunch of 50 cent words peppered throughout a cacophony of statements that is marketing speak meets technical mumbo jumbo, go search online for taxonomy advice. Holy cow Batman, can things get any more confusing? It is pretty ironic that a topic that focuses on creating clear and concise content organization can be so darn confusing. It is no wonder so many projects skip this important step. We are firm believers of cut to the chase and that is precisely what we aim to do here as we walk through some key points of taxonomy and its relationship to great web site navigation.

Looking past the big words, what is taxonomy?

Taxonomy = classification
Classification = another way of saying organization
Organization = groups, associations and labels

Taxonomy is about grouping site content together and creating associations between those groups. Then you label everything so it is discoverable.

It is easy as web developers and designers to get wrapped up with the cool factor of the web. How many different things can you do to your web site to make it sexy? How far can you push the technology and just how tiny can you get all your files? All of those things have their place, but none of us would be here if it wasn’t for the need to get content out to users, and in the most discoverable way possible.

Connecting users and content

In order to make content discoverable to the largest number of users, the grouping, associations and labeling of the content has to be generalized. It needs to be simple and friendly. A great test that can be conducted is to present web site content to someone as if they were a new hire to the company or brand new to your Internet site. Give this person a few tasks that would result in a detailed content search. For example, have the user find:

  • Contact info for their assigned Human Resources representative
  • Product dimensions for installation use
  • Expense report form and how it should be submitted

Immediately the user will mentally label the task with a larger, more general access point(s) where they think they will find the information and then look for that access point on the web site. Everyone scans web pages. Users do not look at each link and carefully consider if that link could lead them to their ultimate destination. Looking at the examples again, here are some likely labels that the user would assign to each task:

  • Contact info for their assigned Human Resources representative
    Human Resources, Contacts
  • Product dimensions for installation use
    Product catalog, Product search, Product detail
  • Expense report form and how it should be submitted
    Forms, Employee Services, Accounting

Every user goes to a site with a task and they have already mentally labeled that task with what they think the access point should be. One of the main goals when creating site taxonomy and navigation is figuring out what labels/access points users will associate with their tasks. Those labels should be the site navigation.

There isn’t a magical tool that will generate site navigation. It simply comes down to knowing your content and users and creating a path to that content based on simple and common sense labels, groups and associations. Often these are multifaceted. With the large amount of content in most web sites, there are usually nested groups, several associations and multiple labels for one item of content. This can be tedious to think about but is essential for discoverability.

Mega menu anyone?

Users think in many different ways. Each of the example tasks above will generate multiple labels when the user considers possible ways to find the information. User 1 could easily think "Human Resources –> Contacts" while User 2 thinks "Contacts –> Human Resources". So what goes into the site navigation? Human Resources or Contacts or both? Pick one for a lively and long team meeting over the subject or do both and watch your navigation quickly spiral out of control with too many options.

There is another path. Use a mega menu to create an educational and/or multi-labeled navigation system. Put in place key words that will catch the user’s eye (they are just skimming the page after all) and tell the user what to expect from a given site content area. Perhaps the user is presented with this:

  • Departments
    • Human Resources
      Benefits, contacts and important forms.
    • Accounting
      Submit reports, request payments and contacts.

This could easily be done in another way using multi-labeled navigation:

  • Departments
    • Human Resources
      • Benefits
      • Contacts
      • Forms
    • Accounting
      • Submit report
      • Request payment
      • Contacts

If the site is limited to a more traditional drop down menu, the same level of detail and information can’t be presented in the first glance. Instead multiple fly out menus have to be used (awful usability), or just rely on users to hunt for the information (frustration galore for the user).

When building out content for a mega menu, consider the path the user will take to arrive at that content. What are the labels, organization and associations? How can the information be presented in a clear and concise way that will get people to the right place as quickly as possible with the least number of false starts? Happy users = great site.

I’ll turn the keyboard over to Dustin now for the SharePoint nitty-gritty.

SharePoint List for Nav Item Storage

Now that the CSS and markup is complete (from part one), it’s time to create a SharePoint List to store the navigation items.

Our list is set up with a self-referencing lookup field so that it’s easier to link any navigation item to any other item, making a hierarchy of links. Remember: this Mega Menu has two levels of links, with the second level optionally grouped together.

Get set up

  1. Create a custom list. Give it a name: "navlinks" (you can change the list to have a "prettier" name later).
  2. Update the list settings to include some new columns:
    • URL (Single line of text)
    • Description (Multiple lines of text, with enhanced rich text)
    • Parent Link (Lookup field, connects to navlinks list and returns Title)
      • Under "Add a column to show each of these additional fields", select ID
      • All other column settings should be left at the default
    • Group (Choice field)
      • Create these choices: None, Products, Services, News, Other
      • Default value: None
  3. When finished, add some data.

Custom Views with XSL

Time to create a custom view to test out the Mega Menu. You’ll be taking the SharePoint list content in XML format and transforming it into HTML using XSL.

Wait, what?

XSL. You know, Extensible Stylesheet Language? I plan to write up a nice SharePoint-friendly primer for a future article. For now, here’s the important part:

One template will create the wrapper around the custom output, and the other template is the repeating section used to build the list items themselves.

The XSL

The XSL will include two "templates", which are used to transform the data that comes from SharePoint into HTML:

  1. "/" (which ends up being the wrapper around the repeating section of your output)
  2. "Row" (the repeating section itself)

Things get a little trickier with a list that can be grouped. SharePoint has one way of doing grouping of list items, and frankly, it’s not the most elegant or efficient way of doing it. The XSL for the Mega Menu should be elegant and efficient.

How does SharePoint do it?

When you group list items in a SharePoint list view, the XSL that generates that view loops through each item in the list and compares each line of data to the previous line of data. If the grouped by field changes, the template spits out the HTML that will be used as the new group-by header, and then emits the HTML for that item. If the grouped by field stays the same, it skips the header and just emits the item HTML.

Simple, it seems. But inelegant. It’s nearly impossible to change the CSS styling of elements like this, and the output (from SharePoint’s default grouping template) isn’t truly nested. The Mega Menu requires a series of nested list items.

What the XSL needs to do

Ready? Take a deep breath.

  1. Create a nav element (cuz HTML5 r0x0r5) with a ul child. Inside the ul
  2. Start looping through items that don’t have a Parent Link specified. For each of those items:
    1. Create an li element with a CSS class name based on the Title of the link
    2. Inside the li, create an a element and also the Description (which SharePoint automatically wraps in a div tag)
    3. Create a ul inside the li for the second level of links
    4. Figure out if the second level of links has a Group or not:
      • If yes, the ul gets a CSS class to make it easier to style
      • If no, the ul doesn’t get a CSS class
    5. Render the second generation of links by matching the Parent Link:ID to the current item’s ID
    6. Close the li element
  3. Close the top level ul and nav elements.

Still here? Got a headache yet? Mega Menus are historically one of the harder things to automate with scripting or templating because the relationships can be difficult to ascertain without a hierarchical data source, like an XML file. Most end up being hard coded. By taking a flat SharePoint list with a self-referencing lookup field, this Mega Menu template creates its own hierarchy on the fly.

Enough theory; show me the code

Okay, okay! Here’s the XSL.

That’s all for Part 2!

"Woah, woah, woah. Wait a minute."

I know. You have questions. You want to know how to use this XSL, how it works, and how to get this mega menu into the master page.

Consider this a cliffhanger. :)

See you back here for Part 3!

How to Map a Document Library in My Computer


You may also be interested in: Documentation Toolkit for SharePoint


 

Editor’s note: Contributor Alexandru Dionisie is an Internet Professional and Technical Writer. Follow him @AlexDionisie

Before we start, you should know that I wasn’t able to get this working in Windows XP. It only worked in Windows 7.

In a SharePoint Team Site click in a documents web part. In the Library Tools command group click on Library tab and then click on the Open with Explorer command.

2013-03-25-MapDocLibrary-01.png

After opening the document library in Windows Explorer, either execute a right click on the general path (a), or on the full path (b).

From the contextual menu (c) click on Copy address option (d).

2013-03-25-MapDocLibrary-02.png

After copying the address go to My Computer and then click on the Map network drive command.

In the new opened windows specify a drive letter and then paste the copied address.

2013-03-25-MapDocLibrary-03.png

Now, the documents library from SharePoint 2010 is visible in My Computer as a mapped drive.

2013-03-25-MapDocLibrary-04.png

2013-03-25-MapDocLibrary-05.png

Mega Menus for SharePoint – Part 1 of 3


You may also be interested in: fpweb.net


 

Editor’s note: Follow contributors Heather Solomon and Dustin Miller @spexperience

In this three part series, Heather Solomon and Dustin Miller will explore the ever-popular "Mega Menu", and how to create a powerful, styled and functional mega menu for use on your SharePoint sites. In this first part, the focus is on the HTML markup and CSS styling used to create this oft-requested UI element.

As a teaser to get you going, here is a quick screenshot of the final product, which we will have after the third post in this series.

2013-03-22-MegaMenu-Part01-01.png

The Markup

Hello, folks! Dustin here, and I’m going to dive right in and discuss the markup Heather and I will be using to create a SharePoint-friendly mega menu, and the rationale behind that markup. Yes, that’s right. No SharePoint.

Wait, what about SharePoint?

What about it? SharePoint is not the business requirement here. The business requirement is to create a mega menu. It’s our strong belief that the business requirements inform the technology decisions, not the other way around. Since, in this case, the requirements for the mega menu consist of the HTML and CSS that will be used to present the navigation, that’s what gets created first. Leave SharePoint out of it. SharePoint is a dirty word. For now it is, anyway.

Functional requirements

In simple numbered-list form, so it’s easier to verify that they’re being met:

  1. A series of links to be categorized under a top-level menu item
  2. Links should allow for arbitrary HTML markup for their descriptions
  3. Links should optionally support categorization or grouping
  4. Markup should allow for flexibility in styling
  5. Markup should allow for easy enhancement with client-side scripting

Technical requirements, A.K.A. HTML Markup

We’re both big fans of clean, semantic markup. As a developer with designer skills, I always try to create markup that isn’t only easy to manipulate with client-side scripting (JavaScript) but server-side processing and building as well (XSL). Additionally, the markup that’s created should be easily reusable; thoughtfully designed HTML can be repurposed on multiple sites with little effort.

In this case, the navigation is truly a list of navigation items. Each navigation item will have a "child" list of sub-navigation items. Since it’s a mega menu, it should also have the ability to group sub-navigation items. Perhaps grouping could be used for categorization of the second level of navigation links, or may just be used to render them into columns or blocks. Heck, this structure should be flexible enough that one could create a ribbon-style UI with only CSS.

Top level links

It’s a navigation menu. How about some links? And, hey, why not throw in some HTML5 markup so the menu can hang with the cool kids. A nav element will act as the wrapper around the mega menu, and a simple ul (un-ordered list) will contain the links themselves.


<nav> <!-- Container start -->
    <ul> <!-- Top level links start -->
        <li class="nav-SearchEngines">
            <a href="#">Search Engines</a>
        </li>
        <li class="nav-TimeKillers">
            <a href="#">Time Killers</a>
        </li>
        <li class="nav-OurStuff">
            <a href="#">Our Stuff</a>
        </li>
    </ul> <!-- Top level links end -->
</nav> <!-- Container end -->

Requirements met?

Requirement number one is met already. Top level menu items used to categorize the links.

Requirements number four and five are met (so far) as well. The markup is clean and simple. There are extra hooks for CSS and client-side script that be used to style each top level link in a different way without resorting to index-based selectors. The class name used on the li element is based on the actual text content of the link — something that will be easy to automate later once the custom SharePoint view is built to generate the mega menu.

Second level: Ungrouped links

The second level of the mega menu will allow for links to be a simple list of navigation items, but should also support the ability to group those links into categories or other semantic structures. First, un-grouped links. Structurally, since these links are "children" of the top-level links, the top level li items will contain a child ul element with the second-level links.

Each second-level link can include a div element that will support any markup one would want to use to describe the link.


<!-- Previous markup snipped -->
<li class="nav-SearchEngines">
    <a href="#">Search Engines</a>
    <ul>
        <li class="nav-Google">
            <a href="http://www.google.com/">Google</a>
            <div>
                <p>Just cuz you're used to it.</p>
            </div>
        </li>
        <li class="nav-Bing">
            <a href="http://bing.com">Bing</a>
            <div>
                <p>
                    <span style="text-decoration:underline">B</span>ing
                    <span style="text-decoration:underline">I</span>s
                    <span style="text-decoration:underline">N</span>ot
                    <span style="text-decoration:underline">G</span>oogle
                </p>
            </div>
        </li>
    </ul>
</li>
<-- Additional markup skipped -->

Requirements met?

The div elements contain the description of the links, so requirement number two is met. Requirements four and five are still being met by this added markup; classes and simple markup will make this easy to style and enhance with script.

Second level: Grouped links

Now it gets a little trickier. How should the markup show that links are grouped, while still ensuring that the menu is easily styled with CSS and enhanced with JavaScript?

I thought about this one for a while, and it came to me: The groups of links are, themselves, items in a list. A list of groups. The links in each group are sub-lists beneath each group.


<li class="nav-OurStuff">
    <a href="">Our Stuff</a>
    <ul class="nav-hasgroups"> <!-- Groups list begin -->
        <li class="navgroup-Products"> <!-- Grouped links for "Products" begin -->
            <h1>Products</h1> <!-- Name of group -->
            <ul> <!-- Links for "Products" group begin -->
                <li class="nav-Widgets">
                    <a href="http://google.com/search?q=widgets">Widgets</a>
                    <div>
                        <h2>
                            <img alt="" src="http://placehold.it/75x50.png"/>
                            Widgets and thingamabobs.
                        </h2>
                        <p>Read all about our widgets and thingamabobs.</p>
                    </div>
                </li>
                <li class="nav-Dongles">
                    <a href="http://google.com/search?q=dongles">Dongles</a>
                    <div>
                        <h2>
                            <img alt="" src="http://placehold.it/75x50.png"/>
                            Dongles and doodads.
                        </h2>
                        <p>Read all about our dongles and doodads.</p>
                    </div>
                </li>
            </ul> <!-- Links for "Products" group end -->
        </li> <!-- Group links for "Products" end -->
        <!-- Additional grouped links snipped for brevity -->
    </ul>
</li>

Requirements met?

Requirements one, two, four and five are still met by this code. Number four was the tricky one, but by adding "nav-hasgroups" as a CSS class to the ul containing the groups, styling should be simple. Requirement three specified that the links should optionally support categorization or grouping; the latest example markup meets the grouping requirement.

So far, so good.

The markup is done (and you can download it here: http://spexp.me/megamenusource).

Next up, Heather takes over and walks through the first round of CSS to style the list so it looks like a menu.

The CSS for the Markup

Now that Dustin has created the markup for the mega menu, it needs to look like actual navigation you would see on a web site and not just a simple bulleted list. Using just CSS, the list can be converted into a dynamic navigation bar with drop down menus and hover effects.

There will likely be other bulleted lists in the site’s content, so a parent element should be included in the CSS selectors so only the mega menu is styled and not every list on the page. In this example the parent is "nav" but it could be anything such as "div" or a class or ID assigned to the parent element.

Additionally most of the selectors in this sample use child selectors – it is the greater than symbol (>) between the elements. A child selector is more specific than a descendant selector which would omit the greater than symbol. A child selector dictates that the following element must be a direct child of the preceding element whereas the descendant selector says the child element can be anywhere within the preceding element, even if that means three nested levels down. Since our HTML structure is nested groups of data, the child selectors are needed so we can specifically target a certain level of the lists.

The other thing included with this code is a LOT of comments. Adding comments is vital for CSS maintenance (and sanity) and really helps when you get into more complex CSS such as this.

Convert to a simple horizontal menu bar

  1. Before the content can get styled into a navigation bar, there needs to be less of it shown to the users. The idea is after all for all the content to be within an interactive menu. This first selector is going to target the child lists that contain the content, absolute position it which removes it from the natural content flow, and then move it off the visible screen.

/* ---------- Menu - Level 2 ---------- */
nav > ul > li > ul {
    position: absolute;
    left: -9999px; /* Hides the content */
}

  1. Now that the list is simplified, the bullets need to be removed from the list. Altering the list style will remove the bullets but the spacing still remains so the padding and margin also need to be zeroed out.

/* ---------- Menu - General ---------- */
/* Remove default list formatting */
nav ul {
    list-style: none;
    padding: 0;
    margin: 0;
}

  1. There are two different ways to convert the unordered list to a horizontal bar. One, float the list items. Or two, change the display for the list items from "block" to "inline" or "inline-block". This really boils down to personal preference or which one will support the finer details of the design. We have used both. For more in-depth information about this, check out Float vs. Inline-Block. This example will use float. When you float any element, you have to specify a width. It can be auto or a fixed width value.

/* ---------- Menu - Level 1 ---------- */
/* List item container */
nav > ul > li {
    float: left;
    width: auto; /* Required for the float property - Can optionally set a fixed width here */
}

Floating an element removes it from the natural flow of the content and places it on top like a stickie note stuck to a piece of paper. The list container (ul) is a block level element. Floating the list items (li) within it creates the horizontal text flow of the menu. Floated elements will stack up next to each other. The floated list items don’t appear at the top of the web page because their positioning is relative to their parent, which in this case is the list container (ul).

  1. This style statement can be expanded to include properties that take this boring text to something that looks more like web site navigation links. The following will add some space around each navigation item, color the background and add a border to the left side of each item so we have a visual separation of navigation links.

padding: 10px;
background: #614B59;
border-right: 1px solid #ADACA2;

  1. The previous style statement is formatting the list item container, but not the text itself. Since this text is wrapped in anchor tags, a new style statement is needed that uses a selector that targets the anchors within the list items. It is always a great practice to write the selector three times, using the pseudo classes that are associated with hyperlinks. Pseudo classes act like modifiers for the selectors. Once the anchors have been targeted, set the font color, family (typeface) and size.

/* List item text */
nav > ul > li > a,
nav > ul > li > a:link,
nav > ul > li > a:visited {
    color: white;
    font-family: Calibri, Verdana, sans-serif;
    font-size: 16px;
}

  1. To round out the navigation text, add a hover effect. The hover is created using the hover pseudo class in a new style statement that specifies what should change when you mouse over the text. Typically you see changes in the background treatment. If the change between off and hover state backgrounds is drastically different, the hover text color needs to be modified as well.

/* List item container hover effect */
nav > ul > li:hover {
    background: #BFC47D;
}

/* List item text hover effect */
nav > ul > li:hover > a {
    color:black;
}

Here is a screenshot of what has been done so far to our menu:

2013-03-22-MegaMenu-Part01-02.png

More cool factor can be added in a little while. This is a good stopping point for the basic navigation bar and it is time to switch to how to show and style the content under each navigation item. Here is a cumulative and organized copy of all of the code created so far:


/* ---------- Menu - General ---------- */
    /* Remove default list formatting */
        nav ul {
            list-style: none;
            padding: 0;
            margin: 0;
        }
        
/* ---------- Menu - Level 1 ---------- */
    /* List item container */
        nav > ul > li {
            float: left;
            width: auto; /* Required for the float property - Can optionally set a fixed width here */
            padding: 12px;
            background: #614B59;
            border-right: 1px solid #ADACA2;
        }

    /* List item container hover effect */
        nav > ul > li:hover {
            background: #BFC47D;
        }

    /* List item text */
        nav > ul > li > a,
        nav > ul > li > a:link,
        nav > ul > li > a:visited {
            color: white;
            font-family: Calibri, Verdana, sans-serif;
            font-size: 16px;
        }

    /* List item text hover effect */
        nav > ul > li:hover > a {
            color:black;
        }

/* ---------- Menu - Level 2 ---------- */
    /* List container */
        nav > ul > li > ul {
            position: absolute;
            left: -9999px; /* Hides the content */
        }

Show and style the level 2 menu – a.k.a. your drop down

  1. The first selector written out for the CSS moved the child unordered lists (the contents for each navigation item) off the screen so it wasn’t visible to the users. It can be displayed again by changing that placement to put it back on the screen. Since the contents should show when the user hovers over the navigation text, the selector that will show the content again will use the :hover pseudo selector. Duplicate the menu level 2 list container selector created earlier and change the left property value:

/* Show 2nd level lists when parent item is hovered */
nav > ul > li:hover > ul {
    left: 0;
    top: auto;
}

There is one thing that needs to get tweaked when this style statement is added. The second level lists are being absolute positioned and therefore are no longer in the natural flow of the content. Absolute positioning is set by specifying values for properties like top, bottom, right and left. For example, left: 15px. This would place the element 15 pixels in from the left side. The trick is which left side? Left side of the browser? Not necessarily. The starting position is based on the position of the parent. This is where the tweak comes in. The parent needs to be called out as the starting point for positioning. In this case, it is the list item container for the first level menu. Adding this property will set it as the starting position:


position: relative;

There is already a style statement for this selector so the new property can just get folded into it:


/* List item container (level 1) */
nav > ul > li {
    float: left;
    width: auto; /* Required for the float property */
    padding: 12px;
    background: #614B59;
    border-right: 1px solid #ADACA2;
    position: relative;
}

  1. The drop downs are now popping in on hover but look totally blah. It is time to go back to the style statement that controls the initial left positioning and start adding some more styles. If you are using a handy browser add-on/tool/extension that allows for live editing and preview of the CSS, it can be helpful to temporarily hide the left property that moves the list off the screen while you work on the styling. Just remember to focus on how it looks when you hover instead of how it looks when you do not. Move the opening comment characters before the left property as shown below.

/* List container (level 2) */
nav > ul > li > ul {
    position: absolute;
    /* left: -9999px; Hides the content */

}

Start adding properties to create a background and optionally, a set width. The following adds a background color, sets a border on all sides but the top, sets a fixed width so the pop-up content has plenty of space and adds a top margin to move the drop down menu away from the navigation item text.


background: #E3E2B3;
border: 1px solid #BFC47D;
border-top: 0;
width: 250px;
margin-top: 10px;

  1. Once the container has been styled focus can turn to the list items within. Just like before, create a selector that targets second nested list items and add properties to control the style. In this example padding is added to move the text off the boundary edges and a top border is added to help create definition between the list items.

/* List item container (level 2) */
nav > ul > li > ul > li {
    padding: 10px 8px;
    border-top: 1px solid #614B59;
}

  1. A hover effect can be added as well to the second list item level.

/* List item container hover effect */
nav > ul > li > ul > li:hover { 
    background: white; 
}

Check out a screenshot of menu updates:

2013-03-22-MegaMenu-Part01-03.png

The menu can be considered done, or you can add a little bling. Before the bedazzler is whipped out, here is an updated copy of the cumulative and organized code:


/* ---------- Menu - General ---------- */
    /* Remove default list formatting */
        nav ul {
            list-style: none;
            padding: 0;
            margin: 0;
        }
        
/* ---------- Menu - Level 1 ---------- */
    /* List item container */
        nav > ul > li {
            float: left;
            width: auto; /* Required for the float property - Can optionally set a fixed width here */
            padding: 12px;
            background: #614B59;
            border-right: 1px solid #ADACA2;
            position: relative;
        }

    /* List item container hover effect */
        nav > ul > li:hover {
            background: #BFC47D;
        }

    /* List item text */
        nav > ul > li > a,
        nav > ul > li > a:link,
        nav > ul > li > a:visited {
            color: white;
            font-family: Calibri, Verdana, sans-serif;
            font-size: 16px;
        }

    /* List item text hover effect */
        nav > ul > li:hover > a {
            color:black;
        }

/* ---------- Menu - Level 2 ---------- */
    /* List container */
        nav > ul > li > ul {
            position: absolute;
            left: -9999px; /* Hides the content */
            background: #E3E2B3;
            border: 1px solid #BFC47D;
            border-top: 0;
            width: 250px;
            margin-top: 10px;
        }

    /* List item container */
        nav > ul > li > ul > li {
            padding: 10px 8px;
            border-top: 1px solid #614B59;
        }

    /* List item container hover effect */
        nav > ul > li > ul > li:hover { 
            background: white; 
        }

    /* Show 2nd level lists when parent item is hovered */
        nav > ul > li:hover > ul {
            left: 0;
            top: auto;
        }

This wraps up the first part of this series. We would love to hear your feedback. Please post comments below and stay tuned for the next post. Thanks!

SharePoint: No more meeting minutes!


You may also be interested in: ViewPoint for SharePoint


 

Editor’s note: Contributor Ellen van Aken is an experienced intranet adoption manager. Follow her @EllenvanAken

When I visit “collaborative” sites, e.g. for a team, a department or a project, I often find a document library called ”Meetings”, or even worse, several document libraries, each for one particular meeting date. These generally contain documents for prereading, presentations from the meeting, agenda and minutes. And sometimes they have an action or decision list as well.

2013-03-18-MeetingMinutes-01.png

The good thing is that these meeting documens are now in one clear online location, and that (hopefully) sending documents via email and printing are reduced.

But now think again. It is 2013.

  • Do you still store everything in document format, while there are ways to do things directly online?
  • Do you have to open multiple Meeting Minutes or Decision List documents when you are looking for that one decision from early 2012, but forgot the exact date?
  • Is there still someone responsible for writing down “refer to next meeting” for several agenda items in the Meeting Minutes, and then remembering to add them to the next meeting agenda?
  • Are you still emailing various draft agenda’s to your team?
  • Does someone in your team have to collect the progress of the action list and recreate the new Action list?
  • Do you have to chase everyone for approval of the meeting minutes?

A different approach.

It may be time to move to a simpler process. Of course, there is the Meeting Workspace but sometimes you prefer to have everything in one site. The MW will also no longer be supported in SP2013. An alternative is the Meeting-Agenda-and-Minutes List, combining agenda, meeting minutes and decisions in one list. Our team started this in about 2002 and we have happily used it for our weekly team meeting for years.

The concept is as follows:

  1. Everything you discuss is first, an agenda item. The owner of the item creates and manages it themselves.
  2. All items not marked as “completed” are visible.
  3. The meeting owner adjusts the order of the agenda items just before the meeting.
  4. During the meeting, the item is discussed. We always had online meetings, so we viewed items on-screen. The item owner can adjust the item while discussing, and show the updates to the team.
  5. After discussing the item, the decision and date are added to the item and the status is set to “completed”.
  6. All completed discussions are stored in one or more “completed” views, sorted and grouped as needed.

Example

Does it sound complicated? Let me show you the (Custom) list that I have worked with.

This is an item on the agenda:

2013-03-18-MeetingMinutes-02.png
This is the item to discuss.By default, status is “New”.

This is the agenda, sorted on “Order” and filtered by “Status is not equal to completed”.

2013-03-18-MeetingMinutes-03.png
This is the agenda for the upcoming meeting.

During the discussion, the relevant info and decision are captured in the bottom fields of the item.

2013-03-18-MeetingMinutes-04.png
During discussion, the relevant information can be added.

This is the view that shows all items that have been discussed. You can easily filter for specific topics, regardless of meeting date. Of course you can also group on other metadata, but this view clearly shows the increased transparancy compared to Meeting Minutes in document format.

2013-03-18-MeetingMinutes-05.png
All decisions from earlier meetings, grouped by discussion date.

Of course you can simplify or extend the list to fit your own meeting style and goals.

What are the advantages?

  • No need to send agendas via email; if everyone sets a notification you wil get a message when a new item has been added or changed.
  • The meeting owner can easily adjust the order of items
  • During the meeting, the item is open and any next steps can be added straight away
  • When something is not discussed or no decision has taken place, it simply stays on the list. You do not have to specifically state that it is “moved to the next meeting”.
  • One archive of individual decisions means you do not have to look through documents by date. Now that you have one “online database” it is much easier to find any decisions relating to your topic, since they can be found by date AND by creator AND by tag if you have used those.
  • Everyone has seen the decision so there is no need to circulate any meeting minutes for approval.

Will this work for all meetings?

Of course this needs change management. If your organization is relying heavily on documents, not used to PC’s and projectors in the meeting room, or has been pampered by people sending things to them, this will be a big change that will need discussion, training and an extensive trial period.

It may be wise to measure time involved in the current meeting setup beforehand and to compare that to the new setup. This informaton will also help you to convince others.

For some meeting types this setup may not be appropriate. There may be legal requirements to have documents, perhaps even printed, with handwritten signatures, or some external participants may not have access to your SharePoint environment.

But for your average team, department or project group meeting, this may save lots of time!

Have you used something similar? Please share!

I got SharePoint for Free, now what?

 

Editor’s note: Contributor Ben Henderson is Manager of Sevices at Colligo Networks. Follow him @ben3003

2013-03-18-SPForFree-01.jpgI read a SharePoint Pro blog post earlier this year, “We Bought SharePoint–Now What?” and it got me thinking, people actually pay for SharePoint?

How do they pay for it?

Do they pay in the time it takes up trying to deploy the software? Do they pay in the amount of time it takes to get end users up to speed? Do they pay for the hardware needed to run SharePoint, or the cloud service of choice? Do they pay for the customization needed to get the software to meet the business requirements? Do they pay for the 3rd party tools that allow them to integrate the software into their environment? Do they pay for the training that end users need?

I remember when SharePoint was free.

If the customer was even slightly sitting on the fence with whether to go for SharePoint or another solution, it seemed like Microsoft would just remove the price tag. Also with the amount of MSDN licenses out there , it’s also got plenty of installations from people just testing the software. But those people are still paying for SharePoint and will no doubt go on paying more and more as time goes on.

What would happen if you didn’t pay?

There are companies out there running the free version of SharePoint, no customizations, and no hardware plan. In fact it’s usually on an old desktop machine under somebodies desk and has grown organically through the organization, as people understand the potential. This is OK though, as it grows people start adopting when they feel like it, not when they are told. When they have a spare Friday afternoon they will look into it and learn it at their pace, if they want to.  The main issue with this (and there are many more) is that it will end up as another system that people can use. It will sit in a bucket with DropBox, File Shares, Box.net, OpenText, and will die a death with only some users using it, and no support from IT or the business to invest in support and maintenance of it.

So back to the blog title, “I got SharePoint Free, now what?”, it’s fair to say you best get your wallet out if you want SharePoint to be even close to a useful business tool.

SharePoint: Easy Row Level Security


You may also be interested in: O’Reilly – SharePoint 2010 at Work


 

Editor’s note: Contributor Scott Shearer is a a SharePoint evangelist and developer with FlexPoint Technology. Follow him @ScottJShearer

Frequently, I have a need to set security on each row of data entered for solutions I provide to my customers. Typically, security needs to be set based on the value selected in a lookup column. Once I deploy a solution, I want the Site Owners and SCAs to be able to easily maintain the solution I have provided. To meet both those requirements, I have devised a simple and easy to maintain method of setting security on each row of data when it is entered and changed.

The technique I use includes a lookup list, another list of any type where security is set, a number of SharePoint groups and a simple 1 step workflow.

Here is an example of how to implement this technique. The scenario is that we have 3 teams in an organization: Finance, Logistics and Sales. When a team member makes an entry in a list, only members of his team should have Contribute permissions. Approvers for his team should have Approve permissions. Everyone else in the organization should have Read permissions.

1) Create SharePoint Groups

In my example, we are going to use the following 6 SharePoint groups:

  • Finance
  • Finance Approvers
  • Logistics
  • Logistics Approvers
  • Sales
  • Sales Approvers

Create these groups before moving to step 2.

2) The Lookup List

Create a custom list and name it ERLS Lookup. The title column will be used as the lookup value in a related list. Next add 3 person or group columns. Set them so that both people or groups can be selected and do not allow multiple selections. Name the person or group columns Read Access, Contribute Access and Approve Access.

Populate the list as follows:

2013-03-18-RowLevelSecurity-01.jpg

3) The Target List

Create a custom list and name it ERLS Demo List. Add a lookup column to the list and name it ERLS Lookup. Have the lookup column get its data from the ERLS Lookup list Title column. Make this a required fileld and do not allow multiple values.

2013-03-18-RowLevelSecurity-02.jpg

4) The Workflow

Create a new list workflow and select the ERLS Demo List as the target list. Set the workflow to run when an item is created and when it is changed. Create an impersonation step – this will be the only step in the workflow. Add a “Replace Item Permissions” action – this will be the only action in the workflow. Select “Current List” as the list on which to set permissions.

Now, the fun part…

Note: you will want to save the workflow a number of time as you are creating it – this is a good habit to have. I learned this the hard way…

Click on “these permissions”. Here we will set permissions on the list item based on the value selected in the ERLS Lookup column.

  1. Click on “Add”
  2. Select “Read” as the “Permissions to grant”
  3. Click on “Choose”
  4. Click on “Workflow lookup for a user”
  5. Select ERLS Looup as the data source and Read Access as the field. Select Display Name as the return field.
  6. In the “Find the list item” section, select “Title” as the field. Then, click on “fx” next to “Value”. Leave “Current Item” as the Data Source” Select “ERLS Lookup” as the Field from Source. Then select “Lookup Value (as text)” in the “Return Field As” section. Then click on “OK”
  7. Click on “OK” again in the “Lookup for Person or Group” dialogue. Select “Yes” when the warning message box pops up.
  8. Click on “OK” one more time to return to the “Add Permissions” dviewfor the worialogue box.
  9. You shouldnow be back at the “Replace List Item Permissions” screen.
  10. Repeat steps 1 though 9 , but select “Contribute” as the permission to grant in step 2. When you get to step 5, select “Contribute Access” as the field.
  11. Repeat steps 1 though 9 one more time , but select “Approve” as the permission to grant in step 2. When you get to step 5, select “Approve Access” as the field.
  12. Click on OK in the “Repace List Item Permission” screen.
  13. Save and publish the workflow.

2013-03-18-RowLevelSecurity-03.jpg

2013-03-18-RowLevelSecurity-04.jpg

2013-03-18-RowLevelSecurity-05.jpg

2013-03-18-RowLevelSecurity-06.jpg

5) Test

Create a new entry and select Finance in the lookup column. Wait for the workflow to complete – a new column is added to the defalt view for the workflow and will show the workflow status. If the workflow indicates an error, go back and fix the workflow. If it shows as complete, view the premissions on the list item. The permissions screen should indicate that the row of data has unique permissions.

The idea here is that, once this is set-up, all that needs to be done to control access to each row of data is to add/remove users from the associated SharePoint groups.

Give it a try!

Build a Search Driven Solution with SharePoint 2013 – Part I


You may also be interested in: SharePoint Conference.ORG 2013


 

Editor’s note: Contributor Nicki Borell is a SharePoint Evangelist & Consultant for Experts Inside. Follow him @NickiBorell.

Part I is about Search Driven in on-premise environments

Part II will show the options and differences with O365 SharePoint Online Search Driven Solutions which are not new in SharePoint 2013. But with SP2013 they reached a new dimension and there are many more out-of-the-box web parts and options to work with content that is in your search index.

Admin Stuff

Why would you use Search Driven? Good question. Let’s ask “why not”? The answer is the index latency. Search Driven Solutions are based on the search index and that means that the data freshness depends on the index freshness. With the new feature Continuous Crawling and other solutions like Event Driven Crawling we can come up with a really up to date index. Depending on your environment you can obtain index freshness in the scope of 2 minutes or so. Some other points in the context of Search Driven Solutions are:

  • Separate presentation from storage
  • Flexible and dynamic
  • Breaking down site collection boundaries
  • Eliminate large list thresholds
  • Allows flexible & dynamic publishing

Special Data means Special Search and special Search Results

In some cases we don’t have to choose between normal SharePoint Search and Search Result web part or using Search Driven Solutions. There is a very useful and powerful option in between. With SharePoint 2013 there are some new features. In the context of “Special Date means Special Search and special Search Results” we will now have a closer look at “Result Source” and “Query Rules”.

Result Source

Working with search based solutions generally we start with a “Result Source”. Result Sources are places under Site Settings or if you were to configure them for the complete farm in the search service application. A Result Source has some basic parameters:

Protocol: defines from where the results are coming

Type: focused between content and people search

Query Transformation: gives us the option to focus on which data is shown in this Result Source using Search Syntax. Also we have the option of using the Query Builder to define the Query Transformation.

2013-03-19-2013SearchDrivenSolution-01.jpg

To use a Result Source we have to configure the search result web part to use this source. This is simply configured in the settings of the result web part:

2013-03-19-2013SearchDrivenSolution-02.jpg

Query Rules

Query Rules are used to manipulate search query. A Query Rule is always based on a Result Source. That’s why we have to start with a Result Source. Query Rules are also based in the site setting or in search service application. Working with Query Rules we have two main parameters.

  1. Query Condition: this parameter defines under which condition the Query Rules takes effect.
  2. To do this we had several options. The easiest way is “Query matches Keyword exactly”. But we also can use Term store using the option “Query matches Dictionary exactly” This brings many powerful options. For example if you extend your Term set which is referred, you do not need to reconfigure you Query Condition. Also this can be useful in a Multilanguage environment.

  3. Actions: The section configures what should happen if a Query matches.
  4. We can configure a promoted result which is similar to the Best Bets we know from SharePoint 2010 and we can place a Result Block.

Result Blocks are a new feature that allows us to place a separate block containing the data we configured based on our Result Source in the top of the search result web part. Every Result Block can be configured using Query Builder. For example if you use a special Result Block only showing pictures the configuration should be like this one:

  • Query: {subjectTerms} contenttype:image
  • Settings: Item Display Template -> Picture Item

Display Templates are also a new feature in SharePoint 2013. They allow us to use different visualizations based on content type or so. Click here for more details

Here is an example:

2013-03-19-2013SearchDrivenSolution-03.jpg

Bring all this together we can deliver special search for special data.

2013-03-19-2013SearchDrivenSolution-04.jpg

To get a result like this we had to configure a Result Source, based on the Query Rules and then use the Result Source in a search result web part. A detailed step by step walkthrough is shown in the Webcast at the end of the post.

Search Driven Publishing Model

The above solutions are all based on a search query which had to be filled in a search box by a user or had to be configured as a “fixed keyword query” in the settings of the search result web part. Now let’s see how we can create dynamic pages showing content based on Search Querys using the new web part family “Search Driven Content”.

2013-03-19-2013SearchDrivenSolution-05.jpg

As you can see there are preconfigured web parts for different scopes. The context driven web parts like “Popular Items” and “Recommended Items” are based on search analytics, user context and user activity. Other ones like “Pictures” or “Pages” containing a special visualization based on the contented type. The “Search Driven Content” web parts can also be used to visualize search results based on a search query which is typed into a search box. All search web parts can be combined with each other. This is used in configuring the following example:

2013-03-19-2013SearchDrivenSolution-06.jpg

Here you can see the “Search Driven Content” web part for Pictures. In the settings dialog the Display Template is configured to show “Picture on top, 3 lines on bottom”. Under Property Mappings you can choose which Managed Property’s are used to fill the lines. In the context of the shown Refiner web part “Refinement Target” is configured to the “Search Driven Content” web part Pictures. The binding is based on the Title of the web part.

Solutions based on the Search API

The Search API allows building Apps or other solutions based on the content coming from the search index. For more information about the SharePoint 2013 Search API look here: LINK

Here is an example based on my demo environment:

http://win-ful28kv4389/_api/search/query?querytext=’contenttype%3Aorbeabike’

Using this query the result looks like this:

2013-03-19-2013SearchDrivenSolution-07.jpg

Using this XML we built a demo App showing the same data like in the above shown search result web part using the Result Blocks:

2013-03-19-2013SearchDrivenSolution-08.jpg

Webcast with hands on system demos:

2013-03-19-2013SearchDrivenSolution-09.png

Clever use of the Search Box web part in SharePoint 2010


You may also be interested in: SharePoint Portals in minutes by SharePoint Implemented


 

Editor’s note: Contributor Wendy Neal is a SharePoint 2010 Developer/Architect for GreatAmerica Leasing Corp. Follow her @SharePointWendy

This is something I stumbled on completely by accident, however it turns out that it’s a cool use of the Search Box web part. Did you know that you could direct the Search Box web part to any page you wish, and it doesn’t have to be a standard SharePoint search results page? In this post I will show you how I configured it to send the search query to a page containing a Business Connectivity Services (BCS) list as the target results page.

We have a search area at the top of our Intranet home page that allows users to search for site content, people, and dealers (see figure 1).

2013-03-19-SearchBoxWebPart-01.png
Figure 1

Originally it only had tabs for All Sites and People, and recently we wanted to add a tab for Dealers. When users enter search criteria on the All Sites tab, they are taken to the standard results page in our Search Center, and when searching for people, they are taken to our people results page. However when searching for dealers, we wanted to redirect them to our Dealer Search results page which was created using the BCS (see figure 2).

2013-03-19-SearchBoxWebPart-02.png
Figure 2

The tabs were created using Christophe’s (@Path2SharePoint) Easy Tabs solution. The tabs for All Sites and People were built using the Search Box and People Search Box web parts respectively and configured to redirect to the proper search results page.

One idea I had was to create an HTML form web part for the Dealer Search box, that when submitted would take the user to our Dealer Search results page by passing the search terms through the query string (the BCS list is connected to a query string filter web part). Then I would have to try to style it the same way as the sites and people search boxes, and this looked like it would be a pain. I wondered if there was a way to simply utilize the Search Box web part for the dealer search by pointing it to our Dealer Search results page instead of the standard results page.

The only way to find out was to try it, and it worked! Following are the steps I took and configuration settings for the web part. Note: this is assuming that you have already created a results page with a BCS list that is populated via a query string filter web part (see figure 2 above). I won’t be explaining how I created the BCS list in this post as there are plenty of resources already out there.

  1. Add a Search Box web part to any web part zone on your page.

2013-03-19-SearchBoxWebPart-03.png

  1. Make sure to hide the scopes dropdown and default to the target results page, as below. Search scopes are irrelevant in this scenario, so you don’t want the scopes dropdown menu to appear. In addition, I left all the other options under Scopes Dropdown and Query Text Box at their default values, with the exception of the query text box width, as I wanted it to be wider, and I unchecked Append additional terms to query.

2013-03-19-SearchBoxWebPart-04.png

  1. In the Miscellaneous section, I left all the image URLs at their default values, but you may change if you wish (e.g. if you’re using custom images for your search boxes). I also made sure the four options below that were unchecked, and I changed the Target search results page URL to the URL of my Dealers BCS list page.

2013-03-19-SearchBoxWebPart-05.png

  1. I changed the Title and set the Chrome Type to "Title Only" since I’m using Easy Tabs. The title is what appears as the tab name. If you’re not using Easy Tabs you may wish to hide the title by selecting "None" or "Border Only."

2013-03-19-SearchBoxWebPart-06.png

  1. Click OK and save/publish the page.

That’s it! Now when you type in a search term in your Dealers search box and click the Search button, you will be redirected to your BCS search results page!

This article was originally posted on Wendy’s blog SharePointWendy.

How to Achieve a Mega Menu Using Out of the Box Navigation in SharePoint 2013 and jQuery


You may also be interested in: Documentation Toolkit for SharePoint


 

Editor’s note: Contributor Paul Hunt is a SharePoint Solutions Architect at Trinity Expert Systems. Follow him @cimares

I was looking at some requirements from a client for their new SharePoint 2013 Intranet, and one that caught my eye was desire to have Feature images on the top navigation.

The requirement was to have a dynamic top navigation, controlled using the SharePoint out of the box navigation settings, but have the ability to add a Feature image and some text to the menu. My first reaction was to think about a custom navigation control in the master page using Tokens in the navigation settings, then I got to thinking, could we do this with JQuery instead?

Here’s a brief mock-up of what they wanted to achieve.

2013-03-18-MegaMenus-01.png

So this weekend I decided to take the matter offline and have a play in my SP2013 development environment and this is what I came up with. If nothing else, it’s a great example of what you can do with some well placed tokens and a little jQuery code!

The first thing I did was take a look at the options available to us in the out of the box navigation, Not much has changed to the navigation interface in recent versions of SharePoint apart from the addition of Managed Metadata base navigation now in 2013. For this example, I’m just using the standard Navigation that forms part of the basic site structure, however there’s no real reason why you couldn’t use the same token based system in the Managed metadata.

2013-03-18-MegaMenus-02.png

In the actual navigation pane, I’ve added some standard links, and then finally a tokenised link that I’ll be using the jQuery to replace.

2013-03-18-MegaMenus-03.png

The real key with what I wanted to achieve is to make it easy for the client to be able to change the data that exists in these Big menus. So if we edit one of the tokenised options, you can see that we’re just using the default out of the box navigation fully.

We place the token in the title field, using the format ~### to denote the start of the token, then a unique identifier for this particular navigation node, and then the closing token identifier ###~. Then the url of the Image that we want to display in the URL field, and then finally the HTML that we want to display in the description field which can include full HTML.

(Note: Audiencing will still work on these menu’s too!)

2013-03-18-MegaMenus-04.png

When we save this back into the navigation, and then display our page, this is the effect we get when we hover over that particular top level node.

2013-03-18-MegaMenus-05.png

So, how did we actually achieve this? The secret is in the jQuery scripts embedded into the master page (In this demo, I’m just using a content editor web part linked to an external html file to make it easy to test and demonstrate!)

I won’t describe the CSS here as it should hopefully be fairly self explanatory and I’ve commented the jQuery code fairly well. I would say that you can and should condense any JavaScript code that you place into your production environment however for demonstration purposes, this code is spaced out and more verbose than I would write for production.. (tldr THIS IS NOT PRODUCTION CODE!)


//First we need to find all of our DOM elements that are in the Top level navigation 
//and contain the start of the token field. 
$("UL.dynamic span.menu-item-text:contains('~###')").each(function(){ 
  
//We then extract the token identifier, removing the ~### and ###~ from either side 
var menuItem = $(this); 
var parentMenuA = menuItem.closest("a"); 
var parentMenuUL = menuItem.closest('UL.dynamic'); 
var menuToken = menuItem.text().replace('~###','').replace('###~',''); 
  
//Then we extract the link to the image, and to the description field (Held in the title attribute) 
var imageUrlHREF = parentMenuA.attr("href"); 
var linkUrlText = parentMenuA.attr("title"); 
  
//Then we hide the tokenised menu item as the user doesn't need to see it. 
menuItem.hide(); 
  
//Now we add an extra class to the Parent UL to apply some CSS 
parentMenuUL.addClass('featuredNavigation'); 
  
//And then wrap the original contents of the menu in an extra div to make styling them into the top right hand corner easier 
parentMenuUL.wrapInner("<div class='navItemsWrapper'/>").wrapInner("<div class='navWrapper' id='" + menuToken +  "'></div>"); 
  
//Finally we build the Featured image with the data from the navigation item 
var imageDiv = "<div class='navWrapperImageDiv'><img class='navWrapperImage' src='" + imageUrlHREF + "' alt='Featured Image'></img>" + 
    "<div class='navWrapperImageText'>" + linkUrlText + "</div></div>"; 
  
//And then inject it into the top of the navigation object using the prepend instruction. 
$('#' + menuToken).prepend(imageDiv); 
});

That’s all the javascript there, though you can download the entire html file that I created for testing and embed it into a SharePoint page using a CEWP to see it in action in your environment.

Navtokeniser.html script file. (Rename from .txt)

I hope it sparked some ideas.

Paul.