Subscribe by Email

Your email:

Current Articles | RSS Feed RSS Feed

Is Xinet WebNative a money saver or money maker?

Posted by Kenny Kirsch on Mon, Mar 01, 2010 @ 08:26 PM
Submit to Digg digg it | Submit to Reddit reddit | Add to delicious delicious | Submit to StumbleUpon StumbleUpon | Share on Facebook Facebook | Share on LinkedIn LinkedIn | View blog reactions 

It's 2010, the worst is over (or so they say). So now it's time to get focused and see how to leverage what you have and maximize revenue. Make a list of your team's expertise and the technology you own and see what new services you can offer or what processes you can improve. Your clients are looking for what's next, so make your offering what's next! Too often companies get stuck in what they know and aren't willing to put in the extra efforts. 

If you're confused – NAPC offers refresher training, online video how-to's (flatheadu.com) and free 1 hour training webinars every other Friday. 

I have leveraged the Xinet WebNative Suite in a couple of large advertising agencies, saved thousands in freelance and created six figure new revenue streams.  Now it's your turn - we at NAPC want to hear about your success stories; not read about the client you lost.

0 Comments Click here to read/write comments

Out with the old...

Posted by Grant Mongardi on Wed, Jan 20, 2010 @ 07:55 AM
Submit to Digg digg it | Submit to Reddit reddit | Add to delicious delicious | Submit to StumbleUpon StumbleUpon | Share on Facebook Facebook | Share on LinkedIn LinkedIn | View blog reactions 

Often, Archiving of Digital Assets and other legacy digital files is an afterthought. Production just runs out of live working storage, and needs to make room, so they drag "a bunch of files" off to an Archiving location that frees the working storage space for use with new projects. There is often little thought put into the process, and the files are just forgetten - until you need them again. If the original plan is lacking, it's possible that you'll find the system lacking.

So what do you need to think about?

 Lots of things, it turns out.

  •  How long will you need to keep the data?
  • Will you need to keep all of it that long?
  • How much can I spend to do implement?
  • How much can I spend to maintain it?
  • How much time do I need to implement it?
  • How often will I need to do it?
  • How quickly do I need to restore it?
  • What regulations or standards are already in place?

Wow. And that's just the big items. There are also lots of little things to consider as well. I hope you have some time, because this could take awhile.

What's first?

Probably the first thing you should consider is whether there are any regulatory or standards bodies that will have jurisdiction over your Archiving process. Many organizations are subject to rules set forth by standards and regulatory practices that institute rules or guidelines that you are required to follow. If you plan your Archiving scheme beforehand, you should be able to meet nearly all of the rules and regulations that these organizations represent. Some things you may encounter in you're foray into Archiving might be:

  • Sarbaines-Oxley
  • ISO 9001/9002/10012
  • ANSI
  • FDA
  • Military/Government Regulations

All of these have at the very least "good practices" guidelines that they expect you to follow. I won't get into them here, but if you're subject to any of those organizations oversight, you should look into the requirements that they impose upon you. Often, they will offer you nearly everything you need to make a well-informed decision.

How long will you need to keep the data?

That's just the simple question. If you're like most of our customers, you have lots of different types of digital assets. In addition to actual WIP, supplied artwork, and purchased artwork, you probably have fonts, process documents (.doc, .xls, etc), templates, etc. If so, you may want to manage these separately, as the need for maintaining (or even Archiving them) may vary depending upon their type and your requirements for storage. For instance, fonts and process documents might only need to be kept for a 2 year period, where actual artwork might need to be stored indefinitely. If you choose to manage these separately, it will make the archiving process more complex, but will save you on storage requirements and tape costs in the long run. In addition, you may decide that for some of your storage needs, charging the customer to maintain their assets is an option. In the WIP case, this is difficult to do, however once you've gotten into Archival data, then it becomes a much more viable option. Archival data requires Real Estate for storage and man-hours to maintain and manage. Those are line items that are difficult to argue. It's not like WIP storage, where storing the data is necessary to produce a product. Once the data is gone from WIP, it becomes a logistics issue, where tapes need to be stored either Nearline, Offline, or Offsite. Nearline storage is the most intrusive and expensive. It requires using up a valuable tape slot, making it unavailable to use for Disaster Recovery or other Archives. Offline means that the tapes need to be stored in a vault onsite, with climate controls and a person to manage those tapes. Offsite means just that - buying storage offsite in a climate controlled vault.

What media options do I have for Archive storage?

This depends upon the prior question and your desire or need for longevity. Generally speaking, for most organizations the choice is limited to magnetic tape, DVD/CD media, or nearline disk. There are other options, which you're welcome to investigate, but these three are the most popular. There are also promising technologies in the works, such as holographic storage and optical tape, but those are at least 5 years away.

Over the years, magnetic tape seems to be the most popular choice for long-term Archival storage of digital assets, although some do use DVD/CD storage, and more organizations are asking about the potential of nearlining assets to disk storage. Some of this decision does depend upon your budgets and the amount of data that you are Archiving, but only to a lesser extent. Nearly any organization can afford to purchase at the very least a stand-alone tape drive for archival purposes, and then just manually write files to tape. If you're still writing Archives to DVD/CD manually, you should probably consider the possibility of adding a stand-alone tape drive. It will make your process much more efficient, and allow you to store Archives in a more supportable and reliable fashion.

Magnetic tape is the most popular choice among our clients, as most require a Disaster Recovery backup, and have already chosen to have an attached library for that purpose. This makes the choice for tape much simpler. In general, magnetic tape stored properly will last 15-20 years or more. Tape degradation is possible, and over extended periods of time data loss can occur, however assuming that Archival tape is only written once, and the tapes are then stored (once full) in the proper environment, you should be perfectly fine assuming that the data will be there when you need it. That also assumes you remember where you put it in 20 years. NAPC generally recommends that any Archival data is written to two separate tapes. This ensures that whatever happens to one copy of an Archive, you will still have a second option for retreival. Tape, being a magnetic media, is vulnerable to magnetic fields and humidity, and to a lesser extent humidity and temperature variations, so proper storage is essential to longevity. Probably not a good idea to store it on top of a large electric motor, or inside the Large Hadron Collider room.

Anectdotally, DVD/CD media appears to be more prone to data degradation than does tape (or disk for that matter). DVD/CD media is very sensitive to bright light and temperature variations, as well as air pollution and humidity. Also, the quality of manufacture seems to dramatically effect this media's longevity, as does the age _before_ writing to the media. You can purchase all different types of writable DVD/CD media, some even with a gold media layer. The manufacturers may tell you it lasts as long as tape, however our experiences, and the experiences of our customers seems to contradict that. Mind you, duplicate DVD/CD Archives, which we also recommend with Tape-borne Archives, can alleviate most of these concerns, as having a duplicate copy of your Archives ensures that the files would need to be damaged on both media before you would ever lose a file. It's very difficult to guage an effective life expectancy however, as we've seen DVD/CD media that is unusable after only a year, and then some that has lasted 10 years.

Nearlining Archives to disk has been gaining ground lately. The idea is that you present inexpensive, slower disk to your Xinet server, and move Archives to that disk, and then just running a tape backup or mirror/snapshots of that data for Disaster Recovery purposes. Given the relatively small expense of adding a large quantity of disk to and existing Enterprise storage device and the simplification it provides, this has been becoming more attractive to larger organizations, as it allows them to run Enterprise-level backups along with their existing backup strategies. For some organizations, this makes documenting and managing these Disaster Recovery schemes simpler for the purposes of explaining them to standards and regulatory inspectors. That alone can sway the powers-that-be to allocate monies for the expense. The scenario is typically more expensive than tape, however, and unless there are other more enticing rewards for doing so, it can be a less viable option. The reliability is generally the same as that for live data, in that only if the device fails in such a way that data on the disk is lost, will the data be lost. Most enterprise-level storage maintains the data it stores via various error-checking schemes, so the chance of data loss even over lifetimes greatly exceeding that of tape are slim. However most organizations would replace the underlying device(s) long before that. I hope.

So which should I chose?

That's not an answer I can offer. It definitely requires some study on your part, and depends largely on what sort of work you do, and what your actual needs are. You'll probably spend a lot of time in meetings discussing the actual needs of your customers and end-users, and what exactly their requirements are, as well as what your needs and resources are. If you need any assistance or guidance in how to best approach this, you should feel free to call your NAPC Account Representative, and they will be happy to help point you in the right direction.

Where can I get more information?

The Council on Library and Information Resources has some good resources on media:

CD Media

Magnetic Tape

And as always, feel free to contact NAPC for any help in defining your Archiving strategy.

1 Comments Click here to read/write comments

Hello, I Work At NAPC

Posted by Robert Sullivan on Fri, Jan 15, 2010 @ 08:08 AM
Submit to Digg digg it | Submit to Reddit reddit | Add to delicious delicious | Submit to StumbleUpon StumbleUpon | Share on Facebook Facebook | Share on LinkedIn LinkedIn | View blog reactions 

I've got nothing this week as far as the work I do 'for' NAPC.
But I would like to talk about working 'at' NAPC. We just announced the other day
that NAPC is making a contribution to the relief effort in Haiti. We're not tossing in
millions of dollars like some of the celebrities I'm reading about, but the whole idea
of course is that lots of people doing something add up to a huge amount.

At our training office in Waltham, we've turned off one third of the lighting in an effort
to reduce our ecological footprint. NAPC encourages employees to seek out and
request alternative energy sources in their private homes, and will foot part of the
additional cost imposed by the local electric company when we do so.

We've had contests to see who could reduce their carbon footprint in our daily commute
into the office. I won one hundred dollars in that contest by slowing down and not driving
as aggressive and staying in one lane. ( Boston driver remember! )
The concept wasn't necessarily to get me to slow down, it was designed to make us think.
Think about our environment. Think about a car pool, or  using public transportation,
or yes in my case, how to get better gas mileage and use less gas.
It worked. 

Believe me, I've had a few employers that I'd just as soon forget.
But it's pretty cool when you're company has a conscience! It feels good to be on that
team. We still have the idealistic leadership that founded NAPC and it's nice to get a
reminder of that every now and again.

So yeah, I've got nothing this week about the work I do for NAPC.
Next time I'll talk about improving your workflow, and tweaking out some more efficiencies.
Today I'm just glad MY company wants to help improve my world.

-Sully
 

0 Comments Click here to read/write comments

WebNative Suite 16 rocks for big databases!

Posted by Rob Pelmas on Thu, Jan 07, 2010 @ 03:27 PM
Submit to Digg digg it | Submit to Reddit reddit | Add to delicious delicious | Submit to StumbleUpon StumbleUpon | Share on Facebook Facebook | Share on LinkedIn LinkedIn | View blog reactions 

I've spent the last couple weeks upgrading 2 of the largest Venture database in existence. One took 6 days, the other 7 to convert everything, but baby was it worth it!


One of the biggest pain points of large Xinet installs databases is performance- to increase  performance when you have Millions (or tens of Millions) of records, you need to 'index' things you search on. In the old version large sites could take a week to drop, repair and recreate the database should something corrupt (and things do corrupt- if someone kicks out a power cable, you're gonna break MySQL tables).

Last week I put an index on the file table of one of these GINORMOUS sites in under 4 hours. Under 4 hours compared to 3 or 4 days! Oh, and during that time? Venture was usable.

That's just awesome.

 

 

2 Comments Click here to read/write comments

2010 and Apple Inc.

Posted by Brian Dolan on Mon, Jan 04, 2010 @ 06:12 PM
Submit to Digg digg it | Submit to Reddit reddit | Add to delicious delicious | Submit to StumbleUpon StumbleUpon | Share on Facebook Facebook | Share on LinkedIn LinkedIn | View blog reactions 
Tags: , ,

Happy New Year all!

 

Since we all work on Macs in some way shape or form, I thought I’d talk a bit about Apple Inc. to start the year.  As a company, Apply is as strong as it has ever been and looks to continue to dominate the consumer market with new desktop & laptop computers, phones and other personal gadgets that are designed to make our lives easier.  Is the Apple tablet computer coming soon???  Hmmm, we'll see!  On the enterprise side, I think Apple did the right thing by dropping the Xserve Raid and continuing to upgrade the Xserve itself.  The Xserve is one of the most popular servers we help integrate into our customers sites especially with small to medium sized Xinet installs as it performs well in those areas.  I think Apple will continue to grow and refine it's Xserve product over time mostly because the server version of Mac OS X is fairly straight forward to maintain by an IT professional compared with other systems.  That's not to say it's super easy to maintain the Mac OS, just a little more "mac" like with buttons to enable a service versus editing a config file in a text editor for example.  You know what I mean right!?!?

 

On another note, MacWorld this year normally would fall on the second week in January but has been moved to mid-February this year.  Why?  Well for one reason, Apple as a company is not going to be exibiting at this years MW and the Consumer Electronics show in Vegas has always been on the same week as MW.  So, IDG (the people organizing MW and plenty of other trade shows) decided to move it out to February.  I for one am happy since there is no "overshadowing" of either show now and . . . I've never been to San Francisco in February!  Yeah, probably not much different than going in January but it'll be something different, I guess....  So, what will Macworld be like without Apple???  My guess is a litte smaller, a little less hype, and less people but, MW lives (for now any way).  Some people say this one will be the last.  I have no clue if that is the case but what I can say is that Apple fans of all types will still be there and even if there is no MacWorld 2011, there still will be passion for a company that makes gadgets intended to make our lives easier.  I'd even bet that there will be more Apple fans next year but I can't say for sure because my crystal ball is not working right now.  It runs on Vista! :)

 

Look for a new blog entry after MacWorld as I will report on what I find while out there.  For now, Happy New Year and may 2010 be the best year so far!

 

Oh and one more thing, if you or anyone in your company plans on attending MacWorld, drop me a line so we can discuss Xinet's new Suite 16 upgrade over an Irish Coffee or whatever adult beverage you prefer!

 

Brian Dolan

<bdolan@napc.com>

0 Comments Click here to read/write comments

The Better DAM Mouse Trap

Posted by Kenny Kirsch on Tue, Dec 01, 2009 @ 10:28 AM
Submit to Digg digg it | Submit to Reddit reddit | Add to delicious delicious | Submit to StumbleUpon StumbleUpon | Share on Facebook Facebook | Share on LinkedIn LinkedIn | View blog reactions 

Here comes 2010 and now is the chance for your organization to leap into the new year with new services and more value.

You thought the hard part was getting the money to buy the technology. The truth is that developing sustainable efficiencies and business models with the technology is harder. It takes leadership and a push for change management. I see many clients talk about all the great things they are going to do with the technology they are going to buy (or bought) – but they rarely do. I recommend making this your New Year's resolution (I hate them too). Think about how to make a few minor changes to your companies bottom line by using the Digital Asset Management system you invested in. Perhaps you have a new online DAM training effort to get your team on board, or have some clients in for a show and tell.

In the coming year – demands will be high to offer better services to your clients. It's a perfect time to deliver the Better DAM Mouse Trap.

0 Comments Click here to read/write comments

The Benefits of Using a CSS Framework

Posted by Jason Palmer on Fri, Nov 20, 2009 @ 12:51 PM
Submit to Digg digg it | Submit to Reddit reddit | Add to delicious delicious | Submit to StumbleUpon StumbleUpon | Share on Facebook Facebook | Share on LinkedIn LinkedIn | View blog reactions 

CSS frameworks have been around for a while, and include popular frameworks such as Blueprint, 960GS, and YUI.  CSS Frameworks are a great way to ensure cross-browser compatibility while working within a clearly defined standard – both of which are extremely valuable in modern web development.

 

Cross-Browser Compatibility

Most of the popular CSS frameworks are cross-browser compatible, meaning that if the developer follows the style guides defined in the framework, the resulting website should look the same in every browser.

 

Some CSS frameworks utilize a reset style sheet to accomplish this, while others simply code toward each given browser to ensure proper compatibility.  Every browser has pre-defined values for given HTML elements.  For example, Internet Explorer may set the body’s default line height to 1.0em, whereas Firefox may set it to 1.1em.  A reset style sheet sets all the default values for every element to the same, thus creating a blank slate for the framework to work from.

 

Well-defined Standards & Constructs

A good CSS framework provides well-defined standards and constructs.  Blueprint, for example, provides a nice grid system that one can utilize simply by setting the proper classes.  So, setting the classes “column span-36 last” will ensure that the element you’re styling will span 36 columns and then will clear so preceding elements fall underneath it.

 

Constructs such as these provide for faster development and also help the developer to design more maintainable interfaces.

 

Tableless Web Design

Every modern CSS framework provides the proper constructs so that the every day developer no longer needs to utilize tables to create complex & beautiful web designs.

 

Tables are VERY slow for the browser to render and should really only be used to render tabular data.  Divs are much faster for the browser to render, more flexible, and just as easy to use as a table with a CSS framework.

 

Conclusion

When developing software, it’s always a good idea to not re-invent the wheel.  Frameworks provide a good, well-tested set of rules and functionality that a developer can code against, thus resulting in better software developed in a shorter amount of time.

 

CSS frameworks are no different.  They provide a developer with a solid base, a rich set of tools, and allow you to lay out your design with confidence that it will be cross-browser compliant, fast, and maintainable.

0 Comments Click here to read/write comments

Understanding Modern, Journalled Filesystems

Posted by Grant Mongardi on Fri, Nov 06, 2009 @ 10:54 AM
Submit to Digg digg it | Submit to Reddit reddit | Add to delicious delicious | Submit to StumbleUpon StumbleUpon | Share on Facebook Facebook | Share on LinkedIn LinkedIn | View blog reactions 
    By understanding how filesystems work, you can hopefully gain a better understanding of how you are and are not at risk. Most modern filesystems used for enterprise storage are what is called "journalled" (or also "transactional"). In this article, I'll try to explain the behaviors of these filesystems in order that you might better be able to assess your risk, and therefore be better able to recover in the event that the unthinkable happens - your data goes away. Please note, that I in no way am implying that the behavior described in this article in any way is universal to all filesystems, only that it is my understanding about most modern-day filesystem that I work with.
    No filesystem is risk-free. There will always be the potential for dataloss, however most enterprise-level filesystems do a good job of preserving the integrity of your files. The various pieces all work together to ensure that your data is there when you need it, regardless of the circumstances. However, the geniuses (and I mean that) that design these systems can't make your files immune to the possibility that we should all know could happen. The idea is to understand that risk, and make the best choices we can to protect ourselves in the event that it does. You may go your entire career without ever encountering this, but better prepared then wanting.
    All hierarchical (folder tree) filesystems contain these two components:
        Metadata
        Data Store
This includes non-journalled filesystems as well as journalled filesystems.
   The Metadata generally includes the superblock and the inode, or file table, which is just an index of the file names, where each file starts being stored on the disk, and where in the hierarchy it resides. It may also contain other infomation such as size, integrity references (checksums), or perhaps storage type (binary or text) as well. This information is used for storage and retrieval of these files, as well as information describing particulars about how this particular filesystem is implemented.
   The DataStore is simply the empty place where the actual file data is stored on disk. Most filesystems break these into blocks of storage of a pre-determined, fixed size. Fixed-size blocks tend to make retreival and writing much faster, as there's much less math for the filesystem drivers to perform in order to find the place where the file is stored and where it ends. There are some exceptions, and these exceptions are typically very optimized for the way they do variable-sized blocks, so any performance hit you take for "doing the math", you more than make up for in having a filesystem optimized for the type of files you're storing on it.
   To retrieve a file, the filesystem looks at the metadata table for the file it's trying to retreive, and then determines where on the filesystem the file starts, and goes and reads that piece. In the process of reading a single file, the filesystem drivers may find that the file is not stored in one contiguous (one after the other) group of blocks. When this happens, it's called 'fragmentation'. No performance filesystem that I know of can totally avoid having some level of fragmentation. As filesystem begin to fill up, with regular file creations and deletions, the filesystem needs to become creative with how it stores these file. Although the ideal situation is to store each file in a contiguous way, it's not always possible without having to rearrange a lot of other allocated blocks in order to get a group of blocks large enough. Trying to do this would make the filesystem incredibly slow whenever you tried to write a file to it, as it would need to perform all sorts of reorginizations any time it wrote a file to big for the available contiguous blocks. Modern disk has improved dramatically in performing these sorts of non-contiguous block reads/writes (known as 'random seeks'), so when a filesystem has a reasonable amount of free space (14% or more), the performance should remain acceptable.
   Now to the hard part - writing files. In order to write a file, the filesystem first determines the size of the file being written, and then it tries to find a group of blocks right next to each other to store the entire thing. Storing files in groups of blocks all next to each other (contiguous), means that the mechanical heads reading the physical underlying disk don't have to move much to get to the next block. For obvious reasons, this is much faster and more efficient. If it does find one, it writes the Metadata, telling the Metadata where it's storing the file, then it writes the actual file data to the Data Store. In the event it cannot find a single group of blocks to store the whole file, it will find the optimum blocks in which to distribute the file across. Different filesystems use different means to describe 'optimum', so I won't get into that here. Suffice it to say, some filesystems are better at it than others. As a filesystem begins to get filled up, the drivers have a much more difficult time in storing files, having to break the file up more, and as such having to perform more calculations to get it all right.

What happens when Murphy's Law strikes?
   Filesystems breaking, or filesystem corruption as it's known, is most often caused by underlying hardware issues such as the physical disk dying or 'going away', or perhaps a power outage (some filesystems are more fragile than others, and can break through regular use, but that's not typical of true enterprise filesystems). If the disk isn't mounted, or there are no writes happening at the time of the failure, the filesystem is very likely to be unharmed, and a simple repair should get it all back to normal. However most enterprise filesystems are in a constant state of flux, with files getting written, deleted, moved or modified nearly all of the time, so having such a failure is often a reason for concern.
   When this failure occurs, any operation that was happening at the time is truncated to the point of the failure. If it was in the middle of writing the file, it means that the entire file not only didn't make it to disk, but parts of the file and file record are likely incomplete, and there's no warning of that other than the broken parts. In a non-journalled filesystem, this means that the damage may not be noticed until someone finds that file that is partially written. When they try to open it, there's any number of possible scenarios. The worst possible scenario is that the storage chain is broken in a really bad way. For instance, the file may start on block number 9434, and then jump from there to block 10471, and then to block 33455, and then back to block 8167. If it died before it had a chance to tell the filesystem all of that, then the filesystem might think it goes from 10471 to 2211, simply because that's the value that was stored for that block prior (or perhaps it's just random data that was there to start with). If 2211 is somewhere within the superblock for your filesystem, and someone tries to resave that file, you've just completely broken your entire filesystem. Oooh, that hurts.
   This is where the jounalling comes in. With a jounalled filesystem, every operation is written down ahead of time in the journal, then the operation is performed, then it's deleted from the journal. In the event of a failure such as described in the last paragraph, when the filesystem comes back up, it will see that there are operations in the journal, and can "roll-back" those operations as if they never happened, hence the filesystem returns to it's last known good state. This ensure that each modification to the filesystem is 'atomic', or only happens when everything is absolutely complete. Even though some of those operations have been completed, the journal is housing all of the not yet complete operations currently being carried out, so when it returns it can just see what was being done and return to what it was before the partially complete operation. Although this isn't totally fool-proof, it certainly is miles ahead of the alternative. This reduces the possibility of a complete data loss failure only to events in which the journal is being written and becomes corrupted, and when the filesystem is also being written and becomes corrupted, and when the Metadata is also being written and becomes corrupted. The likelihood of all three of these things happening is reasonably unlikely where all three things get broken.

I live in a "reasonably unlikely" world. What do I do?
   Regardless of whether you're a lucky person or not, you should always have a good disaster recovery plan. Not only should you have one, you should schedule regular tests of that plan, or at the very least audit it. NAPC has years and years of experience in this area, and can discuss with you the risks associated with your particular configuration, as well as all of the possible scenarios for disaster recovery in the event of a catastrophic failure. To setup such a discussion, contact your Sales representative, or just send us an email!

2 Comments Click here to read/write comments

IE6: Time To Let It Go

Posted by Kai McBride on Wed, Oct 21, 2009 @ 10:38 AM
Submit to Digg digg it | Submit to Reddit reddit | Add to delicious delicious | Submit to StumbleUpon StumbleUpon | Share on Facebook Facebook | Share on LinkedIn LinkedIn | View blog reactions 

A collective groan fills our room of developers at NAPC. Another Internet Explorer 6 (IE6) incompatibility with one our products has been uncovered. The preferred solution is to quit IE6, take a deep breath, and launch a different browser. Unfortunately, for a number of our customers this is not yet an option and we are faced with the challenge of trying to make an old dog (circa 2001) ignore a new trick.

In the late 90s, developing interactive websites required you to choose sides between Netscape Navigator and Internet Explorer. Each offered its own subset of exciting new features that were guaranteed to not work on the other. If you strayed from anything but the most standard HTML tags one of the browsers would fail miserably. Many stale and boring (but functional !!!) websites were born. This was also the era where all colors were picked from the limited "Web-Safe" palette to avoid dithering.   

Thanks to the adoption of standards for HTML and JavaScript, common rendering engines, and Cascading Style Sheets (CSS) most of these show-stopper browser incompatibility issues have gone away, leaving fewer magical incantations that the Web 2.0 developer needs to keep in their toolbox. The majority of these workarounds, unfortunately, have to do with IE6. A quick look at the style sheet for NAPC's Elegant for Xinet Portal reveals a number of hacks to fool IE6 into doing the right thing:

# Ignores the html>body line
hr.mainhr {  top: 120px;  }
html>body hr.mainhr { top: 115px; }

# Ignores the pseudo-commented line
input.btn{ width: 150px; }
/* commented backslash hack v2 \*/
input.btn{ width: 156px; }
/*end hack */


These examples are minor tweaks that take into account differences in the box model used by IE6. More serious issues arise from bugs with CSS v2, ignoring transparency in PNG files, and differences in traversing the HTML Document Object Model. The latter usually results in a breakdown of the friendlier Web 2.0 AJAX features.

And the developers groan.

We are aware that Internet Explorer 6 still commands a significant market share on corporate PCs, and wherever possible we do try and maintain some level of functionality on IE6. However, our products use a great deal of Web 2.0 technology to provide sophisticated interfaces and cutting edge design and IE6 is incapable of keeping up. To be fair, it isn't as bad as IE5 on the Mac was !

With the exciting HTML 5 spec around the corner a number of big players on the web (ex: Facebook, YouTube, Digg) are actively encouraging their users to upgrade or switch browsers. So are we.

2 Comments Click here to read/write comments

DAM Technology dying on the vine.

Posted by Kenny Kirsch on Tue, Oct 20, 2009 @ 02:52 PM
Submit to Digg digg it | Submit to Reddit reddit | Add to delicious delicious | Submit to StumbleUpon StumbleUpon | Share on Facebook Facebook | Share on LinkedIn LinkedIn | View blog reactions 

I am always amazed on how many companies buy DAM technology for their business need and then find out about a new project and look for new technology to buy. Why doesn't the company look hard at what they own and see if it can fill the void? It's a pattern that relates to understanding change and implementation. It's rarely the software, it's the plan, the ability to execute and create the business model they dreamed of before they purchased it. Taking it to the next level, leveraging the investment and keeping current.

Is it lack of effort, no change management skills, no vision, fear of failure or resistance? Perhaps some or all of the above. The problem is most companies don't recognize the most important qualification is desire to CHANGE. If you wait for your users, clients or management to dictate change – it's probably too late (or getting late). 

Look for opportunties to implement the technology, show the benefits, design a plan and create the change. Doing these things make your company better and make yourself more valuable. Is it easy? No. But not changing is not an option.

0 Comments Click here to read/write comments

All Posts | Next Page