Category: Web Design

Posted on

Adobe’s InContext Editing Reviewed

We've really checked it out!
We've really checked it out!

Over the past several months I have really been running Adobe InContext Editing through its paces. I wanted to share with you my thoughts on this new product from my real world use and client testing.

First, Adobe InContext Editing is now ready for client implementation. This is an excellent and exciting new product. It is one that I think, after you read my review, that you may want to consider implementing on your own website.

What does Adobe InContext Editing Do?

This is new online service allows website owners to update their own website content without a webmaster. It is not for everyone, but for some clients it will be an excellent new tool. If you make regular content and image changes to your website, want to have total control over your wording, change your wording when it suits you, or if you want to save money on webmaster services for routine changes, Adobe InContext Editing is perfect for you. At this time, the service is free for developers, but we do expect that in the near future this will change. Your web developer may bill you about $20 per month or so for access to this online application. Set up fees are typically billed by the hour and most sites, that are not over 25 pages, will run about one hour or so to set up the code to allow you to do your own edits. Allow about 15 to 30 minutes for online training to be ready to take over doing your own future webmaster updates.

What can you do to your site with InContext Editing?

You can add, copy, change or delete text on a page at will. You can add images and in general make all of your own website content updates yourself with Adobe InContext Editing.

If you want to add or delete rows in a table (that holds data or images) on your website you have that option.

Additionally, based on the editable region set-up done by your web developer ahead of time, font colors, styles and font sizes can now be under your control as well. 

You can also easily install images by browsing your computer, your website, or the web and insert them on the fly. Resizing your image within the application is easy too.

How is InContext Editing Implemented on My Website?

For developers, set up is pretty straight forward. You configure access in the InContext Editing control panel as you do a typical site for FTP access. The client’s website pages need to be modified to allow for editing. As the developer you can assign editable regions, repeating regions. Font style settings can be detailed for each region. These editable regions are similar yet different to regular Dreamweaver template sections. These special regions carry a special InContext Editing descriptor and a special JavaScript script is installed on your page as well to allow the application to make changes to the page.

I have found that it is best to use Dreamweaver CS4 for setting up the editable regions. You can still hand code in the needed elements in Dreamweaver CS3 but Dreamweaver CS4 makes it much easier and allows you to edit these editable regions you have set up from with in Dreamweaver when changes need to be made. For me, this was worth the $199 upgrade from Dreamweaver CS3 to CS4.

Anything else I need to know?

Adding images does require the end user to understand that they need to click “Advanced” or “Additional Options” on the top right to add a vspace, hspace, no border and an align attribute to make the image look good with in the text.

I have found that the application is easy to use by clients but a bit of online training is needed to help them feel fully comfortable with the interface. That being said, the application is easy to use, intuitive, and for many clients the perfect solution for their webmaster needs.

It is important to know that the end user does not have HTML source code access to the page that they edit inside InContext Editing. If they want to install a snippet of JavaScript they will still need a regular webmaster to install these elements for them into the HTML source code. Additionally, many developers will not allow the client to edit layout items, navigation or other page elements. The developer decides which elements the client can safely edit on the page in advance preventing the website from being inadvertently broken by the client while doing an online edit.

Who should NOT use Adobe InContext Editing?

That is hard to say, most template driven websites that do not allow a developer access to the source code or hosting server would be precluded from using this application. If a developer can access the source code files and can access the server using FTP just about any website can use this product.

Conclusion

My overall impression is that this is an excellent new product and one that will be a “game changer” for webmasters, web developers, and clients. Clients want to save money, they want control over their website and now web developers and designers can make it easy for clients to have the appropriate access.

This application allows for a custom designed website to have many of the features of a online template driven website or the ease of use of a site with a content management system installed without the programming headaches. There will always be reasons for a client to have a webmaster make a special change on their site, but with Adobe InContext Editing easy text updates will be at the client’s fingertips now using their own browser.

From a web designer viewpoint, designing for InContext Editing use does require a bit of a refocus but not a major change. Editable sections need to be set up and enclosed in div tags with unique IDs. 

On one ending note, I have to say that as Adobe has tested this product it has done a remarkable job in its contact with developers and in their support forum. This unparalleled level of participation with the professional community to create a product that will help developers and consumers alike is most unusual and a mark of Adobe’s level of service excellence in the creation of web applications. I believe that Adobe InContext Editing deserves your careful consideration.

Posted on

Adobe InContext Editing Reviewed

Well over this past week I have really been running Adobe InContext Editing through its paces. I wanted to update my post of yesterday which I wrote over seven days ago with my thoughts on InContext Editing from real world use.

First, it is not ready for major client implementation yet. There are too many bugs and issues yet to be worked out for web developers to widely recommend this new product at this point. But, the possibilities are certainly there, and I will be watching very closely. For now these are my thoughts.

1. If you have a website using PHP includes or for that matter any site that uses a header and footer include you will have difficulties in implementing InContext Editing at this point. If you have a plain vanilla website in html you will be fine. I have done testing on both standard html pages and PHP include pages. To make my page editable with PHP includes I had to hard code in the InContext Editing script and special div tag identifiers as when I tried to define the editable div tags online using the interface I triggered a repeating error that refused to set up permissions to allow the page to be edited. This is problematic for Adobe for widespread use, but I am sure they will be working to resolve this as this is an issue for any large website that wants to use their service.

2. If you want to add rows or cells to a table (that hold data not layout tables) on your editable page you do not have that option yet. At this stage the application really only works best for simple wording changes and formatting in text. You can install an image but there is no image preview so unless you know what your image name is ahead of time it is difficult for you to clearly know what image you are adding to your page as you edit. You can not browse and see a thumbnail while you are in the application.

3. Set up of the server is problematic. I understand paths and routinely set up FTP access in several applications and I had trouble setting up the access between InContext Editing and the web server. From my experience, don’t follow the tips in the control panel, follow the online instructions. I achieved a successful set up by not entering www. or ftp in front of my domain name as the instruction stated. Also just set up access for the root, not to a subdirectory as anything other than the root set up will trigger an error. The application wants root access and will not proceed unless you give it that. This may be an issue for testing if you are setting up a client test and don’t want them to have full access to their site. At this time you cannot control what they have access to and do not. Because of this make sure you have a backup before you give any client access to the site through InContext Editing.

4. Adding images does require the client to understand that they need to click Advanced or Additional options on the top right to add a vspace, hspace, no border and an align attribute to make the image look good in the text. It took me a while where to find this. Adobe should make it this like WordPress where you click on the image and then right click to add these attributes not add a link above the content editing field. Many clients write their own blogs so to have it simple like WordPress would be very practical.

5. Web developers should be prepared to pay a subscription fee for this service eventually although it is free for now. Adobe is stating that fees will be $10 to $20 per month for about 5 client websites. If you as the developer then in turn charge $10 to $20 per month per client for access this actually becomes a profit center. I have to say the fee is a non-issue for me. The money that clients will save on paying a webmaster (me included) by doing their own content editing will by far out weigh the very small monthly expense in their eyes. With my minimum charge being $8, to do small updates yourself just twice, you have paid for your access for the month. For small do-it-yourself clients this is a huge money and time saver. Some web designers/developers may consider this an issue of losing income and yes, that is certainly the case for some, but from the client’s stand point it is a money saving feature. Therefore implementation of the service at initial design concept may be a possible closing point.

6. One thing that I think the application would benefit from is a tree view of the site to allow the client to understand the site architecture and to be able to navigate to files easily. The current way you navigate to the page you want to edit is to use the website’s navigation and then click control + E to show the page edit button. For some sites we work on where navigation is to mid pages using anchors this can create a world of confusion for the client who wants to update their own site but not allowing a visual menu of the pages in the site.

My overall impression is that this is an excellent potential new product that will be a game changing for webmasters, web developers, and clients. I am not afraid of it but rather ready to embrace it. Clients want to save money, they want control over their website. This application allows for a custom designed website to have features of a online template website. There will always be reasons for a client to have a webmaster make a special change on their site, but with Adobe InContext Editing easy text updates will be at the client’s fingertips in their browser.

From a web designer viewpoint, designing for InContext Editing use does require a bit of a refocus but not a major change. Editable sections need to be set up enclosed in div tags with unique IDs. It could be a very strong selling point to allow client access to update their content at will as part of selling custom website using this new application as a “bridge”.

I will be watching the product very closely to see when we can include clients in expanded testing and start offering implementation as part of our own web design services.

One quick footnote, I have to say that the forum and support staff for this new product is excellent. They are on the ball, active in the forum, really concerned about the user experience and total code geeks – that’s a good thing, as roll out of this product really depends on the web designer/web developer acceptance of this new product. Way to go Adobe a great new product but one still in the works.

Posted on

Adobe Introduces InContext Editing

What a cool new online tool Adobe has come up with. It is called InContext Editing and allows any site you create with Dreamweaver to be a content management site. Specifically, this means that any site you create with the proper syntax and is set up on InContext Editing can now be edited by your customer using a browser and no HTML knowledge.

To take advantage of this new tool, here are the steps. You set up your site with Dreamweaver templates, locking down certain sections of a page where you don’t want your client to change – like navigation or footer information. Then you set up the “FTP bridge” on InContext Editing and then load your real files and templates to your own web hosting server.

InContext Editing allows the client to login to a control panel, call up a page from their real web server and change the areas that you have approved right there in a WYSIWYG mode. The client can publish the updated page with one click. Clients can even add pages to their site, links, and images.

What a great innovative new product! I will be doing some in-depth testing in the next several weeks and will update my blog with my thoughts after I have really taken it for a whirl, but at first blush, it seems like an excellent tool that allows the end-user to be in control.

What is great from my view point, is that you can create the ease of a content management site without the headaches and programming overhead that a typical content management site needs. On top of that, our websites are built for search engines unlike a content management site that is built for user friendliness, so keeping the optimized code in place yet allowing the client to change wording or add things when they want is an excellent feature.

Right now the application is free, but don’t expect it to stay this way forever. I will be very interested to find out what Adobe feels that they want to charge for the application after they’ve gotten web designers in to take it for a test ride.

In the meantime, you can check out more information and even watch a video demo on Adobe InContext Editing on Adobe.com.

Posted on

Using Dreamweaver Spry and Data Sets

I’ve just changed how my custom website portfolio is rendered. You can check it out here. I used to have a Flash portfolio but now have created a Spry portfolio that uses an XML data set that allows you to click a website name to view an image and accordion style information reveal.

Spry is Dreamweaver’s name for AJAX widgets that use JavaScript and add a new level of interactivity to websites. I already have implemented a Spry drop down menu that runs horizontally across the top of the page of my website at www.McCordWeb.com, but was looking for ways to use some of the other cool new Spry features.

The big deal is that Spry with XML data sets can be used in all kinds of ways. By creating your data set with any attributes you want, you can then use cool Spry widgets to return the data on your web pages without using a database. The XML widget acts as an easy “database” that is client-sided versus residing on your server accessed through a browser action call. The difference is the speed and the fact that your browser performs the functions versus calling up information from your website hosting server.

For me, you can click the column header and sort the websites by name or click the pages header and sort the websites by the number of pages. When you click a link in the list, a new image is shown and data under the image changes. If you click the accordion folds under the image you will see additional dataset information specific to that particular website. The folds open and close based on your click activity.

Dreamweaver facilitates the set up of the features, but it is no walk in the park. I ran into a few major problems in regards to syntax and the fact that the xpath.js file did not render HTML in the accordion folds. It worked fine to show text but when I wanted to show a bulleted list only the source code showed. I upgraded my Spry files and still had problems. I eventually loaded a saved copy of the xpath.js file and all was well.

It certainly pays to do significant testing on the new features if you add them as I did. I found that Safari does not show the accordion tab colors when highlighted as IE, Firefox, and Chrome do. But the major browsers do render nearly everything else the same.

With time to customize the style sheet that controls both the accordion panels and list you can style the widgets to complement your site. All in all, I learned quite a bit about Spry implementation and am looking for new ways to integrate more features. My next project is to “properly” skin my Spry drop down menu and move away from the default skin.

If you don’t know what Spry is or AJAX, click in to my custom web design portfolio and check out the implementation.