Posted Monday, January 31, 2005 10:14:22 PM by Stephanie
How many times have you gotten a contact through your web site asking how much XYZ website would cost? They say, "I want a website like this one." Or ask, "How much would a website for 'this type business' be?" When you ask what their budget is, they don't know. You can spend an hour looking at what they have (if anything), what they want, and then writing a quick guesstimation/quote... maybe you go ahead and spend hours putting together a full estimate. I get them all the time. And sometimes, since I'm rarely the least expensive bidder, they go with someone else -- or no one at all just now. It's just too far outside their budget.
Maybe there's a better way.
I ran across a post tonight on the Signal vs. Noise blog about this very thing. And since I have an estimate waiting, I'm going to use it. It will probably go something like this: Me, "Well, I'd be happy to give you an estimate. What is the budget for your project?" Client, "We're not sure yet. What do you think it will cost?" Me, "OK, so a solution around $80,000 will work?" Client, "Oh no, our budget is more around $X-Y."
This should work to narrow down the budget -- even if the client doesn't think they know what it is. I like this -- a lot. I'll try to let you know how it goes. :)
Posted Saturday, January 29, 2005 11:18:03 AM by Danilo Celic
The Dreamweaver MX release changes things a bit when it came to the Object type of extension. Dreamweaver MX changed the Objects panel to the Insert bar and also added an XML configuration file that is used to specify which tab an object is supposed to be placed on. However, with this change came a change in the way that you needed to package up MXP files for use with Extension Manager 1.5 that came with DWMX. In previous releases of Dreamweaver, installing an Object all you had to do was to specify the folder within the Objects folder you wanted the object to appear and it would show up on the Objects panel in the proper category, even creating a new category if you added a brand new folder.
That functionality changed a bit with Extension Manager 1.5. You had to specifically add some code to your MXI file to be able to create your own category, but you also had to add code to add your Object to a folder, even if that folder already existed. Fortunately, this was removed from Extension Manager 1.6 which can be downloaded found at the Exchange, and is installed with Dreamweaver MX 2004. But if you have users that are on Dreamweaver MX and you can't be sure that they have upgraded their Extension Manager, then you have to add the code to your MXI files.
I found all this out when I was creating an Object that I'll be releasing here at Community MX, and I didn't specify the changes that were to be made to the Insert bar. Worked just fine in Extension Manager 1.6 and Dreamweaver MX, but not with Extension Manager 1.5. Be sure to check the Dreamweaver extensions page for the File Name Link extension soon. While you could read the MXI format document (PDF) and glean a little bit about what you'd need to do, it doesn't really cover the exact code you'd need for making changes to the Insert bar configuration file. See below for code I'm using in the File Name Link extension.
<category folder="Common" id="DW_Insertbar_Common"
<button file="Common\FileNameLink.htm" id="CMX_Insert_File_Name_Link_FileNameLink"
name="File Name Link" />
Reading into this, you can see that you are making a configuration change, in particular insertbar changes, and it is doing an insert into the insertbar. There is a category specified, this tells Dreamweaver which category (tab) of the Insert bar to display your object. If you want to create a new category, then you'd specify that here, this example is placing the Object on the Common category. then using the <button> tag, the file to run and its associated image is specified, along with a unique ID for the inserted item.
Posted Tuesday, January 25, 2005 3:28:17 PM by Stephanie
Those of you with blogs know what a pain it can be when the spammers send their bots out to muck up your comments with links to their own sites. They know the value of a link in Google and they frankly don't care whether they're messing with the rules or messing with you -- they simply want links from anywhere to raise their search engine placement.
Maybe not anymore -- Google has an idea! A new attribute that stops the Google spiders from following a link. You can place it dynamically every time someone leaves a link in your blog. Google says:
From now on, when Google sees the attribute (rel="nofollow") on hyperlinks, those links won't get any credit when we rank websites in our search results. This isn't a negative vote for the site where the comment was posted; it's just a way to make sure that spammers get no benefit from abusing public areas like blog comments, trackbacks, and referrer lists ... We think any piece of software that allows others to add links to an author's site (including guestbooks, visitor stats, or referrer lists) can use this attribute. We're working primarily with blog software makers for now because blogs are such a common target.
Blog software makers are whole-heartedly jumping on the bandwagon to implement this strategy. If you've created your own blog, you may want to add this attribute in yourself. You can read all the details at The Google Blog.
Posted Friday, January 21, 2005 8:59:41 AM by Stephanie
I try to design the code of my pages to be very clean, with little extraneous "stuff." My goal is always to make them as accessible as possible as well as search engine friendly. And I've got it all figured out. Using text instead of images for headings and navigation allows me to be kind to both spiders and people that browse with alternative methods like screen readers. This is one of the main reasons I love sIFR. I can use creative fonts for my headings but still retain the text display in a browser. Yup, I have it all figured out.
When I put images into my pages, I use a descriptive alt attribute if it contains information that a low or non-vision person needs to have. If it's purely decorative, I use the empty alt attribute so that the screen readers will ignore it and not read the name of the file. Yup, all done... good for accessibility... did I mention I have it all figured out?
I belong to a great SEO list, and due to a couple questions going on with a site, I needed to verify some SEO knowledge. While getting into dialogues with the SEO experts there, I'm told that I must put my keywords into my alt attributes. The most important one up to three times in the first few images. NOOOO! Imagine what the people using screen readers will hear -- Blathering keyword ridden yada!
How do I balance the need to be kind to all surfers with the need to be kind to the spiders? Must I choose one or the other? Can I not have a fully accessible to humans site that the spiders also adore? I certainly do not have it all figured out.
Posted Thursday, January 20, 2005 1:32:09 PM by Sheri German
Can we be all things to all people? Probably not, but we're going to try to get as close as possible with the latest CMX JumpStart Dreamweaver template, Liverpool.
This one's really cool. Of course it has the same valid XHTML and CSS and WAI and 508 accessibility features as our previous JumpStart templates. Like the others, it includes a generous bundle of tutorials to help users understand its construction. And naturally there is a folder of source PNGs just waiting for modification and branding. This one has something extra, however. It includes an authentication (login) system with starter files and database for three popular server models: ColdFusion, PHP, and ASP. An "admin" folder includes a set of four files that logs users in and out based on access level. There is a separate tutorial for each server model as well, and some of these tutorials include videos.
If you haven't tried a CMX JumpStart yet, now is a great time to give one a whirl. We don't care if you're on a Mac or PC, or use Firefox, Internet Explorer, Safari, or Opera. We don't care if you prefer PHP, ASP, of ColdFusion. CMX JumpStart Liverpool--living up to its name of "City of Culture 2008"--has something for everyone.
Category tags: Dreamweaver
Posted Friday, January 14, 2005 12:18:05 PM by Danilo Celic
The Dreameaver extensibility documentation contains an error that could cause your variable grid to not display the column widths correctly. The documentation, found at Help > Extensions > Extending Dreamweaver > Contents tab > Overview > User Interfaces for Extensions > Using custom UI controls in extension > Adding a variable grid control , has this code sample:
<select name="ParamList" style="width:500px;" type=mmparameterlist columns="Name,SQL Data Type,Direction, Default Value,Run-time Value" columnWidth="100,25,11," size=6> </select>
The widths of the columns are specified in the columnWidth attribute in
the code above, however, this attribute is actually called columWidths. Note the pluralization of the attribute name.
This error was encounterd by yeudoi in a thread at the Macromedia DW Extensions web forum.
Posted Thursday, January 13, 2005 1:10:18 PM by Stephanie
For a long time I've been the kind of web developer that enjoys writing clean, valid code. I have some web friends that think I'm a little too hard core, but it makes me happy. When I complete a site (or when I run into a problem while developing the XHTML/CSS), I use the Web Developer's Toolbar in Firefox to quickly run the page through HTML and CSS validation. No, I don't put the little button on my sites -- who really cares? But I do make sure it validates.
This week, I had a really odd phenomenon happen. I found myself using proprietary CSS, causing my page not to validate, and then told someone, "Who cares if it validates!" Shocking coming from my mouth... or fingers.
That said, what's validation really for? Is it the end, or the means to an end? Is the goal to create pages that work in the validator? Or pages that work in all major browsers and sell whatever your client is selling?
I've come to believe that if I have to use proprietary code to force a certain browser which shall remain nameless to render code the way it would be rendered if that browser were standards-compliant, and it doesn't harm any other browser's rendering of the page, then I've done my job. If rest of the CSS validates and is written correctly, then I've used my tools wisely and created a site my client can make money from and I can be proud of.
Posted Tuesday, January 11, 2005 10:34:05 AM by Stephanie
Though Search Engine Optimization isn't one of my favorite things to do (gurls just wanna write code!), I do basic optimization for select clients. Of course, this forces me to keep up with the latest news from the Engines to do a good job. Recently, I ran across the Search Visibility Report. SVR is a blog that shows me all the search engine blogs at a glance. So instead of visiting Google, Yahoo! and other blogs one by one, I can simply hit the SVR site (using the Sage extension in Firefox -- my personal favorite), and instantly see what's been said today. Very cool!
Posted Monday, January 10, 2005 4:13:44 PM by Danilo Celic
Dreamweaver MX 2004 supports transparent PNGs as icons in its toolbars, unfortunately, Dreamweaver MX doesn't. MX does support PNGs, just not transparency. So if you're looking to have great looking icons on your toolbar, and you're also looking to support Dreamweaver MX, then you may be in for a bit of a surprise. However, all is not lost, I've found a relatively easy way around this.
The graphics designer at a company that I was creating a custom toolbar for really loved the transparent PNGs that he had created, and I must admit, they did look good. However, the toolbar also needed to support Dreamweaver MX, and when I broke the news that they would need to give up the transparent PNGs of MX 2004 just to support MX, the designer and the company owner, wasn't too happy. The company asked if there was anyway short of creating multiple MXPs, one for each supported version of Dreamweaver, to have the lovely PNG icons for MX 2004 and the adequate GIF icons for MX.
After thinking about things for a bit, I remembered that the toolbar XML files are initialized after the startup Commands are run. So taking that a step further, I placed GIF and PNG versions of the icon images in the toolbars installer MXP, and I created a startup command that would read in the toolbar XML file for their toolbar and edit the paths to point to the proper images based upon the version of the application that the toolbar was installed by by the MXP. Could have been done either way, but since more potential users were in MX at the time, I decided to make GIF the default image specified for the toolbar button icon rather than the PNG version.
Within the startup Command, a quick check of dw.appVersion to determine if any editing might be necessary (only needed for 7.0 and higher), and if so, the Command then used DWfile.read() to get the toolbar XML file contents as a string file, a simple RegExp is performed to see if and references to GIFs were present, and if there were, then simply replace them with the proper PNG equivalent. Then resaving the file using DWfile.write() and the transparent PNG problem was solved, as Dreamweaver would then load in the modified file.
Note: For more on startup Commands: take a look at: Event-Driven Dreamweaver Commands: Startup and Shutdown.
Now, you may have noticed that according to the instructions above, that it looks like the toolbar would get read in every time Dreamweaver is started, and you'd be correct. My first attempt at working about the PNG issue in toolbars, I wrote out a file that I'd check for its existence, and if it was there, I'd assume the XML file had been corrected. Unfortunately, then next time I made an updated version of the toolbar extension, the "already updated" file was still there, throwing off the test for rewriting the XML file, leaving me with the "bad" GIFs when I was expecting the PNG icons. So I went with the read always method, and only performing edits if I found GIFs present, which would only happen the first time Dreamweaver is started after an install, or update, of the toolbar extension.
Posted Friday, January 07, 2005 12:50:56 PM by Stephanie
I hadn't been over to CFOpen.org lately and this morning I surfed in to check it out. It looks to be shaping up quite nicely. For those of you that don't know about CFOpen and are CF developers (or work with CF developers like I do), you should check it out. I'll let them explain a little more:
"CFOpen.org is a collaborative software development environment designed to facilitate the development of open source software for ColdFusion. Using CFOpen.org, distributed, volunteer teams of developers can design, develop and test open source ColdFusion software easily using built in source control, document management, task management, bug tracking and discussion forums.
It is our belief that for a platform to be truly successful, it must engender an active open-source community to provide opportunities for developers to gain knowledge and experience and to provide benchmark applications with which customized solutions can be built."
So basically, they're taking ColdFusion into the open source, collaborative realm. That's cool. For a list of currently open projects -- pre-alpha to mature -- check this list out. It looks promising.
Posted Thursday, January 06, 2005 4:46:03 PM by Danilo Celic
Dreamweaver does not support displaying underscores in the text of a menu item. I found this out when following up to a question in the Dreamweaver Extensions group, How to use the underscore character in a menu extension. For an example, here is the code for a menu item for the Edit > Prefereneces menu item:
<menuitem id="DWMenu_Edit_Preferences" platform="win" name="_Preferences..." key="Cmd+U" enabled="true" command="dw.showPreferencesDialog()" />
Notice the underscore ( _ ) in the name attribute. This tells Dreamweaver that the letter P will be an access key for this menu item. Becuase of this functionality, underscores are not supported as being visually displayed as the text in a menu item. I've even tried escapping them by using \_ and doubleing up on them using __ and neither work. Interestingly, doubleing up does cause an ampersand to be displayed ( & ), but in no case is an underscore displayed.
Subsequently found out from a Dreamweaver engineer that underscores are not handled within the text of a menu item due to the access key functionality.
Posted Tuesday, January 04, 2005 9:53:26 PM by Danilo Celic
If you've been working long in the web world you've probably become accustomed to useing some type of include, be it #include with ASP, cfinclude in ColdFusion, include() in PHP, or other type of server side include. Well, Dreamweaver also offers this to you for use within its extensibility layer.
To include a file into your Dreamweaver extension, use code similar to the following:
<!-- #include virtual="demoInclude.htm" -->
The included file, in this case demoInclude.htm, will be pulled into your extension when it is run by Dreamweaver. The file being included can be referenced using a document relative path, or a root relative path. Root relative paths take as their root the Dreamweaver configuration folder.
Because of using the virtual method of including, Dreamweaver will automatically compensate for files located in the user's folder including files in the configuration folder for the application.
You may recognize this type of include as being quite similar to regular SSI type of includes, and you'd be correct. However, one difference is that the Dreamweaver includes only use virtual and not file references.