Current version of Lightbox (widely used in web development) has an intricate navigation in the image gallery. At first a user trys to guess where to show “previous” or “next” buttons. This navigation isn’t user friendly. Here are some small modifications for creating a simple navigation:

The best way for creating it in your image gallery is overriding the code without direct changes in the lightbox source code. It’s profitable when it is necessary to update the source code.

Note: In the examples we were using lightbox2.04 in folder lightbox, the folder with the names of styles for containing css styles and the folder with the name ‘js’ for containing the java script code.

1. Creat the lightbox_override.css in the styles folder and place in it the next code snippet:

[source='php']
#hoverNav{ height: 40px; width: 100%; z-index: 10;}
#hoverNav a{ outline: none; text-align:center }

/* change height for next and previous link */
#prevLink, #nextLink{ width: 60px; height: 40px !important; background-image: url(data:image/gif;base64,AAAA); display: block; }
#prevLink, #prevLink:hover, #prevLink:visited:hover { background: url(/lightbox/images/prevlabel.gif) left 15% no-repeat;}
#nextLink, #nextLink:hover, #nextLink:visited:hover { background: url(/lightbox/images/nextlabel.gif) right 15% no-repeat;}

/* change image data container height */
#imageDataContainer{ height:40px;font: 10px Verdana, Helvetica, sans-serif; background-color: #fff; margin: 0 auto; line-height: 1.4em; overflow: auto; width: 100% ; }

#imageData{ color: #666; }
#imageData #imageDetails{ text-align: center; padding-left:60px; padding-right:60px}
#imageData #numberDisplay{ }
#imageContainer #bottomNavClose{ position:absolute; float: right; padding-top:2px; width: 17px; right: 10px;outline: none;}
[/source]

2. Creat the lightbox_override.js in the ‘js’ folder and place in it the next code snippet:
[source='php']
/**
* Override lightbox initialization.
*
*/
Lightbox.prototype.initialize = function() {

this.updateImageList();

this.keyboardAction = this.keyboardAction.bindAsEventListener(this);

if (LightboxOptions.resizeSpeed > 10) LightboxOptions.resizeSpeed = 10;
if (LightboxOptions.resizeSpeed < 1) LightboxOptions.resizeSpeed = 1;

this.resizeDuration = LightboxOptions.animate ? ((11 - LightboxOptions.resizeSpeed) * 0.15) : 0;
this.overlayDuration = LightboxOptions.animate ? 0.2 : 0; // shadow fade in/out duration

var size = (LightboxOptions.animate ? 250 : 1) + 'px';
var objBody = $$('body')[0];

objBody.appendChild(Builder.node('div',{id:'overlay'}));

// Change lightbox html code and place next and previous link to bottom of box
objBody.appendChild(Builder.node('div',{id:'lightbox'}, [
Builder.node('div',{id:'outerImageContainer'},
Builder.node('div',{id:'imageContainer'}, [
Builder.node('a',{id:'bottomNavClose', href: '#' },
Builder.node('img', { src: LightboxOptions.fileBottomNavCloseImage })
),
Builder.node('img',{id:'lightboxImage'}),
Builder.node('div',{id:'loading'},
Builder.node('a',{id:'loadingLink', href: '#' },
Builder.node('img', {src: LightboxOptions.fileLoadingImage})
)
)
])
),
Builder.node('div', {id:'imageDataContainer'},
Builder.node('div',{id:'imageData'}, [
Builder.node('div',{id:'hoverNav'}, [
Builder.node('a',{id:'prevLink', href: '#' }),
Builder.node('a',{id:'nextLink', href: '#' }),
Builder.node('div',{id:'imageDetails'}, [
Builder.node('div',{id:'caption'}),
Builder.node('span',{id:'numberDisplay'})
])
])
])
)
]));

$('overlay').hide().observe('click', (function() { this.end(); }).bind(this));
$('lightbox').hide().observe('click', (function(event) { if (event.element().id == 'lightbox') this.end(); }).bind(this));
$('outerImageContainer').setStyle({ width: size, height: size });
$('prevLink').observe('click', (function(event) { event.stop(); this.changeImage(this.activeImage - 1); }).bindAsEventListener(this));
$('nextLink').observe('click', (function(event) { event.stop(); this.changeImage(this.activeImage + 1); }).bindAsEventListener(this));
$('loadingLink').observe('click', (function(event) { event.stop(); this.end(); }).bind(this));
$('bottomNavClose').observe('click', (function(event) { event.stop(); this.end(); }).bind(this));

var th = this;
(function(){
var ids =
'overlay lightbox outerImageContainer imageContainer lightboxImage hoverNav prevLink nextLink loading loadingLink ' +
'imageDataContainer imageData imageDetails caption numberDisplay bottomNav bottomNavClose';
$w(ids).each(function(id){ th[id] = $(id); });
}).defer();
};
[/source]

Difference between standard initialization and custom is in changing html element positions.

3. Include the standard litebox files:

[source='php']

4. Include the ‘css’ customization:

[source='php']

5. Include the java script logic customization:

[source='php']

[/source]

Note: all files included must be located in the head element of the html page.

The waterfall model (one of the approaches to software development or web development project) describes a linear development method that is often considered the classic approach to the systems development life cycle. This model is a sequential model, used to create different kinds of software, where project development is seen as flowing steadily downwards (like a waterfall) through the phases of software development requirements analysis, UI design, software implementation, project verification and software maintenance. The process itself can be divided into different phases, depending on the IT project or other web development requirements.

The main idea of the waterfall model is that software development proceeds from one phase to the next step in a purely sequential manner or way. For example, the wed development team first completes requirements and when all the desired requirements are fully completed, reviewed and approved, the IT team proceeds to GIU design phase. So, the waterfall model means that the programming team should move to a next following step only when previous phase is completed and everything is approved. However in some model modifications some slight or major variations and even changes may be included.

The most important advantage of the waterfall idea is that it allows for departmentalization and managerial control. In the common practice a schedule with deadlines for each phase of project development is made and a product can proceed through the development process under the created schedule.

The next argument for the waterfall model is that it puts solid requirements on theproject documentation (design documents and requirements specs) as well as the source code. And if any of team members left the project, less knowledge would be lost in comparison to a project with less designed and documented methodologies. In the waterfall model a fully working design document should be present so, that a new team member or even the entire new team will easily familiarize themselves with a project by reading the documents.

In common practice waterfall methodologies result in a project schedule with 20-40% of the time invested for the first two phases, 30-40% of the time to coding, and the rest dedicated to testing and implementation time. The actual project organization needs to be highly structured. Most medium and large projects will include a detailed set of procedures and controls, which regulate every process on the project.
In theory, such process leads to the project being delivered on time because of detailed plan for each phase, created previously.

However, in practice it’s often impossible to follow the pure waterfall model, because it does not consider the inevitable changes and revisions that become necessary in the development process. Also, many specialists argue on the waterfall model as a bad idea in practice, generally because of the inability to perfect one stage of a software product, before moving to another stage and learning something new from them for any non-trivial project.
For example, customers may not be sure of what requirements exactly they want before they see a working prototype and can comment upon it; they may change their requirements constantly after seeing a result of development, and program designers and implementers may have little or no control over this. If customers change their requirements after a design document is finished, then the document must be modified to correspond to the new requirements. Also, project designers may not be aware of future implementation or development difficulties when writing a design for an unimplemented software product. For example, it may become clear on the implementation phase that a particular area of product functionality is extraordinarily difficult to implement. In this situation, it is better to revise and change the design document rather to persist in using a conception, that was made based on incorrect predictions and that does not consider the newly discovered problem areas. This is one of the reasons, why the waterfall model isn’t commonly used in agile software development.

So, to conclude – the most significant weakpoint of the waterfall model is the possibility that a poor or wrong design choice will not be discovered until the final stages of implementating or testing. The risk of this happening will increase as the project duration and size go up. Even competent people make simple mistakes and considering the solid waterfall timetable, mistakes made in the design or requirements documents may not be discovered until half of a year of programming have been completed and the system is being tested.
From the author’s point of view the waterfall model in its pure form can be successfully used either on small projects or on trivial projects, where all requirements are known before the project starts and they won’t change over the time. For example, in mobile games development industry all requirements are usually developed and perfected before the project starts, what allows the development team to work on the pure waterfall model. However if there is even a miserable chance that the project is non-trivial or there are non-completed requirements the waterfall model won’t be the best one to work on.