All posts in Webparts

LifeInSharePoint – Metro Weather WebPart

by Christopher Pettigrew on January 28, 2013 in C#, SharePoint, SharePoint 2010, Webparts with 53 Comments
metroweatherwebpart

UPDATE :

Due to an update to the World Weather Online API to a new one, the WebPart is currently having issues raised in the comments. I am working on bringing you an update with the new API and also trying to include time information as well. If you are able to be patient I will bring this asap. Thanks.

Overview

After a couple of days tweaking, and adding some additional functionality, I am happy to release the first version of the Metro Weather WebPart. This WebPart was created due to the lack of (in my opinion) good looking weather WebParts available. The WebPart has multiple modes, built in caching, XSLT rendering and a great look. See below for the release and its features.

Features:

What it looks like:

Now you know the features how about we show you how the webpart looks when it is installed on the page.

Horizontal:

This mode shows the locations horizontally tiled from left to right and when you click on a specific location the forecast will fly out “Horizontally” to the right to show the day of the week, the weather, the temperature (in centigrade or fahrenheit) and the wind speed (in mph or kph).

weather_horizontal

Vertical:

This mode shows the locations horizontally tiled from left to right and when you click on a specific location the forecast will fly out “Vertically” to the bottom to show the day of the week, the weather, the temperature (in centigrade or fahrenheit) and the wind speed (in mph or kph).

weather_vertical

Horizontal Summary:

This mode shows the locations in a single fixed widget displayed “Horizontally” with prev and next buttons to the left and right of the forecast. The weather, the temperature (in centigrade or fahrenheit) and the wind speed (in mph or kph) is shown for each day in the forecast.

weather_summary_horizontal

Vertical Summary:

This mode shows the locations in a single fixed widget displayed “Vertical” with prev and next buttons to the left and right of the forecast. The weather, the temperature (in centigrade or fahrenheit) and the wind speed (in mph or kph) is shown for each day in the forecast.

weather_summary_vertical

How to use:

To use the new Metro Weather WebPart first download and upload the solution to your site collection. After you have activated the feature you are then able to add the WebPart onto the Page and configure the webpart to display the weather information of your choice.

The WebPart has the following properties that can be configured at set:

  • – This is the most complex property to complete. This is a comma and semi-colon delimited string which will configure the location that will be displayed, its colour and if required a different display name.
    • The string should be in the following format: Location{Display Name},Colour;Location{Display Name},Colour
    • Examples from the screenshot above would be: London,red;Las Vegas{Sin City},blue;New York,green;
    • If you emit the {Display Name} then the city name from the xml results will be displayed instead.
    • The avaliable colours are shown in the features above.
  • – This sets the number of days forecast that can be displayed. (The Free API enabled a max of 5)
  • – Before you are able to use the webpart you will need to sign up for an API key at http://www.worldweatheronline.com/register.aspx
  • – This is the XSLT path for the WebPart. The default setting should be: http://servername/Style Library/LifeInSharePoint.Weather/xslt/Weather.xslt
  • – Sets the display type of the WebPart. Horizontal, Vertical, SummaryHorizontal, SummaryVertical.
  • – Sets the temperature setting to either centigrade, or fahrenheit.
  • – Sets the wind speed to be displayed in either Mph, or Kph.

Download

To download this webpart please visit our Codeplex site and as always if you like it please leave a review, and if you find any issues or bugs either let me know via this site or the codeplex site.

Conclusion

I really hope that this webpart comes in handy for the SharePoint community. Really hope you all like it :)

Enhanced Promoted Links for SharePoint 2010

by Christopher Pettigrew on August 18, 2012 in jQuery, SharePoint, SharePoint 2010, Webparts with 13 Comments
promotedlinkspostheader

Overview

Its been a while since my last post so I decided that it would be a good idea to provide some new community content.  As you are all well aware, SharePoint 2013 has been shown to the world and one of the features that have come along with the preview was something known as Promoted Links.  In SharePoint 2013 this is a custom list type with a specific view on the list that showed you your links in a nice enhanced manner with some javascript goodness.  I really liked this functionality so I decided to not only create it for SharePoint 2010 usage but i also enhanced the implementation.

SharePoint 2013 Version

Here is a screenshot of what the OOTB SharePoint 2013 version of the Promoted Links looks like.

As you can see its a very clean and nice Metro Windows 8 style interface.

LifeInSharePoint Edition

So what is new in the LifeInSharePoint Edition?

  1. Sandbox Solution (Works with SharePoint Online / SharePoint 2013)
  2. Reordering enabled like the OOTB Links List (Single post deployment step required)
  3. Customise the Background colour of the blocks using the WebPart Settings.
  4. Custom Link Titles using the WebPart Settings.
  5. Integration with Font Awesome.  If you cannot find a suitable image try one of the hundred odd icons from the inbuilt font.

Screenshots

Download

To download this webpart please visit our Codeplex site and if you like it please leave a good review :)

Usage

To use the new Promoted Links WebPart first download and upload the solution to your site collection.  After you have activated the feature you are able to create a new list from the LifeInSharePoint – Promoted Links list definition.  Once you have created the list please modify the default view and and enable the radio button “Allow users to order items in this view?”  After this you are then able to add the WebPart onto the Page and configure the webpart to point to your newly created list.

Conclusion

As you can see the new version is as close as I could get to the SharePoint 2013 version with my own LifeInSharePoint enhancements.  Should you have any issues or identify any bugs please let me know via the comments.  Really hope you all like it :)

iGoogle UI for SharePoint – Part Three: Saving WebPart states using Cookies

by Christopher Pettigrew on February 28, 2012 in jQuery, SharePoint, SharePoint 2010, Webparts with 13 Comments

Series Content

  1.     Part One – Overview, Concept,  HTML Structure & jQuery Basics
  2.     Part Two – Dragging, Dropping,  Sorting and Collapsing
  3.     Part Three – Saving WebPart states using Cookies – Current Article
  4.     Part Four – Control Adapters
  5.     Part Five – SharePoint 2010 Integration
  6.     Part Six – Bringing it all together
  7.     Bonus – Saving WebPart States using the Client Object Model

Overview

In Part Three we will take the code from our previous post and enable the page to remember the state of the various settings that we have applied such as the WebPart positions, the order, and minimise states and the webpart header colours.

Javascript

For this post we will require a new javascript library to help manage the Cookies stored for each user.  This library has been already included at the bottom of the existing demo’s.  This time however we will finally use it.  This Post will contain a lot of new Javascript and I will try my best to explain all of the items.

Saving the Position

The First thing that we will do is to Save the Position of all of the widgets at different times in the page life-cycle.  The first thing we need to do is dynamically set the Zones setting previously defined in previous posts. as well as add another setting into the definition to store the Cookie settings.

This parameter was left blank on purpose to give the script the maximum flexibility.  So to find out where the widgets are we need to find out what “zones” that the widgets are occupying.  To do this we will create a new function called “defineZones” which will be used to iterate through the DOM and create a comma separated list of zones and their ID’s.  Now a Zone in this tutorial is the ID associated with each column.

The full function is shown below. We will then dive into the details of the code.

Lines 6 – 9 goes through all of the columns defined in the settings.columns property and then creates the string based on the current items ID.  In line 11 i then set the dynamic string to the zones parameter only after trimming the end of the string again.

Now that we have a set of defined zones we need to now set up a new function to save the state of all the widgets contained with each column.

This new function SaveState does the following actions.  To this method we will add first create a new reference to our global object and then we update the Badge Details in-case something new has changed.

We then create a new cookie with the setCookie() method which will use the positionCookie setting to store the cookie key and then call the GetPositionState() method which will return the positions as a comma separated & pipe separated list.

The GetPositionState() method firstly gets a local array of all of the zones we found using the previous method and add it into a new zone variable. Then we create a blank string value to store our positions.  Next we loop through each zone and for that we use the jQuery sortable methods with the “toArray” parameter which will get a comma seperated list of all of the zones and seperate each zone with a pipe character.  Finally we will create a javascript alert of the widgetPositions found.

Next we place the SaveState(); method call into the remove button event handler, as well as the stop method of the makeSortable method so that when we remove or move a widget on the page it will provide us with the new position.

At this stage we now can save the position of each widget when we close and move them on the page between columns.

Retrieving the Position & Order

The next step is to now to retrieve the position of the locations when you load the page so that the widgets appear in their previous positions.  To do this we need to firstly create a new method in our iSharePoint Namespace called loadStateFromCookie. This method will do two things.  Firstly it will load the position state from the cookie and place it into a variable, and then it will pass this to another method ProcessWidgetPositionData which will place the widgets in the correct locations.

As you can see we firstly get a reference to the settings and the local jQuery object.  We then set a custom variable PositionStates to the cookie value by using the getCookie method.  We then pass this into the ProcessWidgetPositionData method and then finally we update the badge method which will ensure that the number of “closed” widgets is correct.  We will now dissect the processing function.

This method is quite long but is easier than it appears.  As we have done for each method so far we need to get our local references to jQuery etc, and then we need to check that we have received some data in the PositionStates variable.  Next we need to split the array of values which we created in the SaveState() method back into an array so that we can loop through them.  We will also need to get the array of zones defined so that we can match up each of the arrays.

Next step is to loop through each of positions in the order array and perform two important tasks.  The first task is to place the correct widgets in their correct columns and then the next step is to ensure that they are in the correct order in that column.  We will firstly tackle the positions:

What this first part of the function does is loops through all of the widgets on the page when it loads and search if the current widget is found in the order variable (using the .search method, if an item is not found then it will return -1) then we want to add that item to the current column (defined in the zonearray).  NOTE: Because we are in control of the order that values are saved into the cookie the retrieval of the items can be predictable.

The next step is to then reorder the widgets in the current column.

This will again ensure that there is a value in the current order value (there can be a column with no items) and then it will split the widget values into an array.   We now have an array of values which are in the order that they were saved so we can now process the array by appending the widgets in the current column again but this time in the correct order.  Simple. :)  The complete code for this method is shown below:

 

Demo

To view a demo of where we have got to thus far click here

Saving the Collapsed State

The next step is to save the collapsed state of each of the widgets on the page.  The first step is to modify the SaveState(); function to include the following line at the end.

This line does what it say and sets the minimiseCookie to the value that is returned from the GetMinimisedState() method.  The GetMinimisedState() is a new method which is going to be added outside of the iSharePoint namespace and will simply go through each widget which has the minimised class attached to it and add it to an array.

That’s it for saving the collapsed state ..nice and simple.

Retrieving the Collapsed State

To retrieve the collapse state is also another simple addition.  To do this we will load the state from the cookie set above and then for each of the widgets defined in the array it will set them to minimised and collapse the widget.

So the first step is to modify the loadStateFromCookie function to include two lines.  The first line is to set a local variable “MinimisedStates” to the cookie value:

the next step is then to process that data by passing it into a ProcessMinimiseData() method.

What this processing method does is split the array of MinimiseStates and then for each item in that array it will locate the widget with that ID.

If there is a widget in the array it will perform a slideToggle and then add the minimised class to the current widget.  The final step to this piece of the puzzle is to ensure that when you click on the button to minimise each widget is to run the save state method.  To do this we just modify the buttonFunctions method with the highlighted item below.

That’s it for this section. :)

Demo

To view a demo of where we have got to thus far click here

Saving the Colour

This section we will save the current colour set in the webparts colour settings panel.  As we built in previous posts the colour widget can be any colour you can think of so we need to find a way to process this data on the fly.  Once again like above we need to modify the SaveState(); function to include another line at the end.

Like before this will set the cookie to the output from the GetWidetColor method.  This method simply goes through each widget and gets the value that is stored in the text box with the class iColorPicker.

When the method loops through each text box it will also pipe delimit the widget id along with the colour so we are able to match them up on retrieval.  Next step..getting the colour back on load.

Retrieving the Colour

To retrieve the colour of the widget is very similar to the previous “retrieve” methods. To do this we will load the state from the cookie set above and then for each of the widgets defined in the array it will set them to colour defined and then re-color the widget.

So the first step is to modify the loadStateFromCookie function to include two lines.  The first line is to set a local variable “ColorStates” to the cookie value:

the next step is then to process that data by passing it into a ProcessWidgetColorData() method.

What this processing method does is split the array of ColorStats and then for each item in that array it will find the widget with that ID using jQuery.Find() and set the Text Box Value, CSS and Handle Selector CSS.   The first couple of lines should be all too familiar by this point.  Below is the full method:

That is all that is required for the colour modifications..we are almost done now :)

Demo

To view a demo of where we have got to thus far click here

Resetting Layout

The final step we need to implement for the base functionality is the ability for the user to “reset” his / her layout back to the predefined default.  To do this we need to add 5 lines of javascript into the buttonFunctions method into the reset button click event.

All this does (its pretty obvious) is delete each of the user set cookies and loop through each colour picker text box and clear the values which will reset the colours.

Summary

So that’s the end of part 3 of this blog series.  It has been quite a long one but i hope that you have all learned something from this and can see how easy it is to combine jQuery and HTML to create a really great interface.  The full js for this post is shown below.  I will be hoping to get the next posts completed faster next time.  Please leave your comments..they are always appreciated.

iGoogle UI for SharePoint – Part Two : Dragging, Dropping, Sorting and Collapsing

by Christopher Pettigrew on September 28, 2011 in jQuery, SharePoint, SharePoint 2010, Webparts with 15 Comments
iGoogle-Part-Two

Series Content

  1.     Part One – Overview, Concept,  HTML Structure & jQuery Basics
  2.     Part Two – Dragging, Dropping,  Sorting and Collapsing – Current Article
  3.     Part Three – Saving WebPart states using Cookies
  4.     Part Four – Control Adapters
  5.     Part Five – SharePoint 2010 Integration
  6.     Part Six – Bringing it all together
  7.     Bonus – Saving WebPart States using the Client Object Model

Overview

In Part Two we will take the basic html from part one and using some Javascript magic make it into a more compelling and interactive page.  Firstly we will identify the various techniques individually and then put them all together at the end of this post.

Javascript

As mentioned in the previous post, a decision was made to use the jQuery Library with the jQuery UI abstraction layer to provide the functionality for our “iGoogle” interface.  It is using this library that will speed up development and keep everything cross-browser capable.  In our solution we will be using the following effects / methods from the jQuery & jQuery UI library.

We will begin by modifying our script.js file to include a new global object called “iSharePoint“.  This will be our namespace that we will use to contain all of the functionality for our interface.  Within this object we will create a set of functionality that uses the libraries and methods described above.

This method will be called from the jQuery Document Ready function which will ensure all the items are ready to be manipulated before we do anything.

iSharePoint Settings

The settings object we have defined will contain all of the global settings we require to make this item as functional as possible.

There are quite a few settings which I will now explain each in detail:

  • columns – this is the class selector for each of the columns that we would like to be sortable and drag and drop between.
  • zones – these are the unique ID’s of each of the columns. (This is blank because we are going to dynamically populate this based on the DOM contents)
  • widgetSelector – this is the wrapper div of each of our draggable widgets.
  • handleSelector – this is the grab handle class for the div we will use to drag the widget around the page
  • contentSelector – this defines the class of the widget content wrapper which is used for the collapsing and expanding functionality.
  • editSelector – this defines the class of the edit panel wrapper which is used to contain the edit functions.
  • toolboxSelector – this defines the footer toolbox where unwanted or unused widgets can sit out of the way.
  • widgetPlaceholder – this is the name of the class that is assigned to the drag target div so you know where your div will end up.

Bring the Widgets to life

The next part is a little more complicated but we will take each part individually.  We now need to add another method to our global object that we will call “buttonFunctions”

To this method we will add first create a new reference to our global object.  This is useful if multiple instances are required as well as if you ever need to rename the global object.  We will then need to create a new variable so we can reference jQuery without using the “$” symbol in noConflict() mode as that symbol it is used by SharePoint’s internal js files and can cause clashes. (Thanks to Chris O’Brien for explaining this here)  We will then create a local reference to the settings only as a shortcut so you don’t need to type “this.settings” every time.

The next step is to define our button click handlers so that each widget has independent click events that can be raised.  One thing to be careful of is what is known as “Event Bubbling“.  This is when, upon clicking on an element in the DOM the event will bubble upwards through to the highest level element which an event the same as the ones you have recently triggered.  To prevent this from happening we need to add a line of code (e.stopPropagation();) which will prevent this from happening.  Below is a skeleton framework of the button click handlers.

As you can see there is quite alot of framework code added to contain the button functionality.

Demo

You can see and example of where we are currently by clicking here for a demo

Button Functions in More Detail

We will now flesh out each of the functions in the method to provide them with some actual functionality starting with the widget toolbox slider at the bottom.

As you can see we have changed line 5 from the alert to

This simple line will enable use to open and close the toolbox at the bottom.  Nice and simple.

The reset button will not be functional at this point as in future posts we will be resetting the cookies and refreshing the page.  At this stage we will simply ask for confirmation of the action and then refresh the page.

 

We have again removed the alert placeholder from the framework above and instead added three lines of code 5-7 which will ask the user to confirm that they want to reset and if they click yes then the page will reload otherwise nothing will happen.  Two down, Three to go.

Next we will add the toggle functionality to the edit toolbar.  This again is another single line but with some nested functions which will be explained.

As you can see we have once again replaced the alert placeholder with the single line.  If we look at the html of a widget we can explain how this works.

What we are trying to do is traverse the DOM to open and close the widget-edit div.  Our starting location is <a class=’edit’>edit</a> which is the first part of the code $j(this).  We then want to get the reference to the current buttons parent only, with a selector of settings.widgetSelector (which in our settings is set to “.widget”).  We then want to find the widget-edit div which is this part of the code find(settings.editSelector) and then we finally ask the code to perform a slideToggle(“slow”).  The slow property creates a nice visible slide.  Alternate values for this can be fast or to not provide a property at all.

So..Whats next.  The next item on the list is the remove functionality.  What we want this to do is remove the widget from the current div that it sits in and place it in the toolbox div.  This div has some specific CSS attached to it which will collapse the whole widget and just show the title bar with no buttons.

This time we are using a similar method to the previous function by traversing the DOM to find the current buttons parent.  However this time we want to take this whole DIV and using the appendTo() method we can attach it to the toolboxSelector div defined in the settings.  Simple!

The final one to do is the collapse button.  This once again is very similar to the edit button but with an extra line afterwards.

Once again you can see that we are getting the reference to the parent and then this time finding the contentSelector to perform the slide toggle on.  Afterwards we are once again getting the parent widget wrapper but this time we are now adding a class via the toggleClass method.  We need to do this so in future posts when we are saving the various states we can easily identify which widgets are minimised.

Thats is it for the button configuration.  We can now delete, open the edit box and toolbox, we can delete a widget from the main view and we can reset the page and force a page refresh.

Demo

To view a demo of where we are so far click here

Adding Drag and Drop functionality

So next up is the nicest piece which is the ability to drag and drop widgets between the columns.  Firstly like we did for the buttons we are going to add another method to our global object that we will call “makeSortable”.  Once again like above we will also add the iSharePoint reference, noConflict and settings references to the top.

To this function we will now add a reference to the jQuery sortable function.  This function takes a set of parameters which will be explained below the code sample.

  • Line 1 : take the reference of the columns from the settings and runs the sortable method on it.
  • Line 2 : this line enables us to connect all columns together so you are able to drag and drop between all instances
  • Line 3 : defines the element that you use to drag and drop
  • Line 4 : defines what the cursor looks like when dragging
  • Line 5 : If set to true, the item will be reverted to its new DOM position with a smooth animation.
  • Line 6 : The class that gets applied to the otherwise white space when you are dragging.
  • Line 7: Self explanitory, forces the placeholder to have a size.
  • Line 8: Time in milliseconds to define when the sorting should start.
  • Line 9: Opacity of the element currently being dragged.

The following lines 10 – 12 and 13-16 are two functions that get run at the start and end fo the dragging process.  The start function is used to change the colour of the columns so that they are highlighted when you drag so you know what the boundaries are.  The stop function reverses this and resets the toolbox and columns back to their previous state.  In future posts we will be using the stop function to save the state of the widgets.

Notifications

You may have noticed by now that there is a div called “Badge” which is displayed in the HTML as a red circle.  This does indeed have a purpose to display the number of items currently in the toolbox.  To do this we once again need to add alittle piece of jQuery magic to bring it all together.

Firstly we need to create a global function which is not in the iSharePoint object.

What this does is count the number of widget divs that are in the toolbox at the bottom using the .Size() method.  The references to the divs are taken from the iSharePoint settings.  All that is needed to do now is to add the updateBadge(); to the ready function.

Then add it to the .remove click event.

And then finally add it to the stop event from the sortable method.

Colour Picker – Edit toolbar

The final piece of this post is to enable the colour of the header to be changed using the toolbox.  To do this we need to add another function to the global iSharePoint object called activateColours which will be used to process the colours.

The Markup for the edit toolbox is as follows:

As you can see this is nothing different from previous code but as you can see there is an LI with a class of each of the colours that you would like to use.  You are also able to put hex colours into the class names and they will work just fine.  The code for the function is shown below:

The first 4 lines should be nothing new as it is the same as previous functions.  The first loop goes through every unordered list on the page with a class of color and sets the background colour of the list item to what is in the class name.  Once all the items have their colour all we need to do is to attach a click handler to each of the list items themselves so they can control their parents header which is what the next loop then does.

Finally we need to add the function to the init function so that it will become active.

Demo

So want to see the whole thing working?  Click here to see the final result of this quite epic blog post.

Summary

In this post we have outlined how to add the various functionality to our page using javascript and the jQuery Libraries.  Next time I will explain how to save the state of the page using Cookies.  I hope this post has been useful and please leave some comments about what you would like to see in future posts.

 

iGoogle UI for SharePoint – Part One : Overview, Concept, HTML Structure & Jquery Basics

by Christopher Pettigrew on August 31, 2011 in jQuery, SharePoint 2010, Webparts with 7 Comments
iGoogle---Part-One

Series Content

  1.     Part One – Overview, Concept,  HTML Structure & jQuery Basics – Current Article
  2.     Part Two – Dragging, Dropping,  Sorting and Collapsing
  3.     Part Three – Saving WebPart states using Cookies
  4.     Part Four – Control Adapters
  5.     Part Five – SharePoint 2010 Integration
  6.     Part Six – Bringing it all together
  7.     Bonus – Saving WebPart States using the Client Object Model

Overview

This is the first in a series of posts which will explain how to create an iGoogle style interface for SharePoint 2010.  More and more clients are asking for an iGoogle or BBC Homepage style homepage for their intranets and out of the box in SharePoint 2010 there is no method to do this.  While you can drag and drop webparts in “Edit Mode” in a WebPart page, end user however is stuck on where to place their webparts on the page.  This series will aim to provide a mechanism where end users are able to take control of their page and make the SharePoint experience more personal.

There are many sites on the internet which have the ability to drag and drop components around the page and save their locations for your next visit.  Some of the most well known examples of this interface are:

iGoogle – http://www.google.com/ig?hl=

BBC Homepage – http://www.bbc.co.uk/

Both these sites give you the ability to drag and drop various widgets around the page.  You can also close widgets you do not want to see and minimise others to maximise space on the page.  This is the kind of interface that we are going to create for use in SharePoint using jQuery and some C# code.

The Plan

First, let’s list exactly what we’ll be creating here and what features it will have:

  • The interface will contain several widgets (WebParts).
  • Each widget can be collapsed and removed via controls on the page.
  • The widgets can be sorted into an unlimited number of columns.
  • WebParts will be have their rendering controlled via a control adapter which will modify their look and feel.
  • Widgets will have their location and states saved using cookies.
  • Creating a simple Visual Studio 2010 solution to deploy an example.

This post will provide an overview of what we are planning to build as well as getting some development environments configured for your own personal demos.

Getting Started

To get started in this post we will be creating a demo environment to ensure that the Javascript, HTML and CSS are all working together for use in future posts.  Initially we will not be touching SharePoint as it is not necessary at this stage.  Firstly we will need to create a base HTML template that will load a specific CSS stylesheet, images and Javascript libraries.

HTML

Below is the base HTML that will be used in our initial demo.  We have a wrapper div that surrounds three div columns called “Left”, “Middle” and “Right”.  Within each column is the widget HTML that will be used to wrap each WebPart.  Each widget has a wrapper div as well as a header and body content divs.

As you can see the HTML is very simple but at the moment it will not look very attractive.  We have each of the widgets in their own Div and in the header we have three images which will be our “buttons” to control each widget.  On the left we have the collapse icon, next we have the edit icon and finally we have the remove icon.  Underneath the header we have an edit panel which will contain in this example some colour selections for the header bar which will be hidden in the css shown below.  So the next task is to now style the page and make it look neater.

CSS

The CSS is fairly simple and will be used for the SharePoint implementation.  We start with a global reset of the page to ensure that all DOM elements are reset.

The CSS helps style the page into three even columns and each of the widgets are styled with some buttons and styled headers.

Javascript

To provide the cool functionality, we will need to get the latest jQuery libraries and jQuery plugins. We will also create our own custom javascript file which we will be used to store our script.  The versions that we are using are below with links to download them.

Our own script.js file at this stage will contain only a couple of lines of code to test that jQuery is working;

Images

The images for the close and collapse buttons we will use a simple sprite which has a close, max and min symbols on it.

Live Demo

A live demo of the base structure can be found here.

Summary

In this post we have outlined what we will be covering and have managed to get a demo environment working for the next phase.  We will add some jQuery functionality and make our page come alive in the next posts.  I hope this post has been useful and please leave some comments about what you would like to see in future posts.

 

← Older Entries