Blog

Dec

2009

Eddy Chan

We hear you, we really do... hang in there!

Many of you have been speculating on the future of BC development in 2010. Folks have been discussing on the forums and sending in wishes. Sometimes we get wind of what you'd like to see in the system through your support requests as well. BC wants you to know that none of this goes unnoticed and that there's been action behind the scenes so as your Product Manager, I'm going to outline our plans for the first half of 2010.

What's Happening With the Wishlist?

First off, let's cover the wishlist - by voting as a community you've shown what your priorities are and we're going to respect that. If you go to the wishlist now you'll see that out of the top 20 wishes, we have committed 10 to our short term roadmap. BC has monthly software release cycles and you should be seeing the following requests trickle out during January, February and March releases in 2010. The plan for the wishlist requests is as follows:

Modules within Modules - we're going to allow one level of recursion with the first version of this
Customizable Workflow Notifications - as BC partners you'll need the ability to edit the workflow emails and welcome emails you send to your clients
Additional 'List Template' Layouts for Web-apps - we're first going to allow a dynamic number of layouts for Web-Apps and when this model is proven it will be applied to other modules and the Online Store as well
Increase the modules per page limit - system uptime and service reliability come first so we will be doing a lot of testing before we raise the limit, expect an incremental increase here
Web App URL Friendly - web apps will gain the same customizable URL system that blog posts currently have
Dynamic Menus Active/Inactive - a 'enabled' checkbox will be added for dynamic menus just as there is for web pages
Plain WYSIWYG Input - An comprehensive overhaul for Sitewalk will be released late in Q1 2010 and this will have provision for plain text input so your clients aren't able to inadvertently change the layout
Products URL Friendly - products will gain the same customizable URL system that blog posts currently with the addition of a special character 'eraser'
CRM Custom Fields updated via Webforms - this will allow your customers to update their own extended CRM details from the front-end.
DNS Enhancements - these were detailed and promised in the last blog post in November

As you can see our engineers are going to be very busy working on these requests as well as the features promised in the last blog post including DNS tools, Data Center migration, a new Dreamweaver Extension and Partner Billing tools too!

The Longer Term Strategy...

As the old cliche goes, if Henry Ford had only asked his customers what they wanted he would've given them faster horses. We've also got our own development agenda running in parallel to wishlist requests. For the first half of 2010 there are 4 areas of the system BC wants to focus on and completely overhaul in priority order.

ECommerce - both in the frontend and backend we are designing a much more cohesive and well integrated online shopping workflow especially with respect to the shopping cart, payment/shipping functionality and order fulfillment
CRM - usability is key here, expect to see improved filter/search and edit functions for records and tighter integration with ECommerce and the CMS
Blogs - we're going to finish what we started this year to bring our blogging platform up to industry standards
Forums - are due for improvements like avatar profiles, private messaging, social features (e.g post voting) and improved discussion threading

Our plan is to sweep out all the corresponding wishlist requests for each component and consolidate as part of the requirements and specification for those components which is why you're seeing some high priority wishes without a set status. Expect to be seeing results in June/July as these are large engineering projects

Continuing Work on Other Components

Web Apps, Email Marketing and Reporting will need to follow in the 2nd half of 2010 and later. This doesn't mean work will stop on them completely, we will continue to make incremental improvements (as per wishlist requests) where possible but the complete overhaul will have to wait until after our top priorities have been implemented.

Hope that answers some of those burning questions you partners have bottled up. It's an extremely ambitious plan but we're confident with our expanded Adobe engineering team coming up to speed with the BC product and codebase that we'll be able to pull this off and keep BC at the forefront of the competition to give you the best Online Business platform for building solutions for your clients.

Comments

Tim Wood commented on 12-Dec-2009 02:53 PM

Eddie
Congratulations BC on displaying some tangible developemnt plans that will produce definite results for the end client/user (and action the wishlist).
regards Tim

Liam commented on 13-Dec-2009 01:47 AM

Hi Edward...

- Modules within Modules:
Always a good thing to hear but as I and others have pointed out - small additions to web apps in regard to just small tweaks and additions of some custom fields Means less reasons to require modules inside modules.
This actually would be easier for you, give more abilities to us and achieve much of what people want from modules inside modules.

- Additional 'List Template' Layouts for Web-apps
Again, can not complain about new features that the system lacks but again not quite the right focus.
For most of us the way web app's work the templates you get here are enough. Not saying I would not mind more but Like many we have a lot more issues with the template limits in the e-comerce more then anything else, reading the forums many others are the same.
Again just that slight wrong focus in my opinion. I know it will role out in other areas after but I can see this rolling out and everyone going "great, but we really need this elsewhere" And actually getting more annoyed knowing its there but not where you need it.

# Increase the modules per page limit
Again something with the wrong angle being looked at.
Why do people need more module limits.

-- Add more custom field types that are needed, change some others sightly to offer a bit more functionality (for example I do not think you get how powerful the _value for the image field is for people, oh and note how image custom field is more a media field these days.)
A custom WYSIWYG field (multiline text field with icon that launches a WYSIWYG model popup should not be to hard to do as all the elements are there for it, this would be massive, this again is something that would reduce a persons need for multiple modules and modules inside modules.

If you can do more in one web app or template layouts (Basic condition statements again here would be a god sent) then your need for the actual wish lists of modules in modules and module limit is reduced and so having to mess to much with the server load and performance would still be done you do not have to do it as soon.

-- Content holders! This is the key. A content holder holds content, it should not be treated as a module and modules inside content holders is important.

-- I have talked about relationships and OO implementation before but I know this is some time away so not fussed.

I am not saying "do these small temporary fixes." Because they are not actually temporary, these cure problems I and many others have when trying to do things.

If I had a custom field for literature items and that had a _value aspect to the tag and the literature items showed their file extensions - That is massive. I have to make other web apps so I can use the editor area for the client for things when it should really be just one web app. People do this now and so would like to put the one module inside the other. As I said, give that module those small bits of functionality first and a lot of need for the more complicated implementation is removed!

All the things your going to do - I am all for it but at the end of the day For much of next year I am still going to have the exact same grips and problems building modern complex sites because the actual issues will not be solved.
As the above stuff your doing roles out a lot more of the user base of the CMS will realise that as well.

The last big concern for me is web standards and semantic mark up.

You guys tout it but when you still output things with border="0" on images despite having it in your css, and then also go put inline styles in things so you can not override them without doing the !important hack, that is not great.
You still do _blank for new windows when you should be using rel="external".
I have mentioned before, again the change for that is small. You change nothing in the admin. All you do is change the output from "target" to "rel" and _blank to "external" add the script needed to the scripts you always call up as standard and you now comply better with validation!

Forms:

comes with a name which is not used for anything by yourselves as you remove it all is still sweet. It is not valid to have name in there. So why do it?
Where are the fieldsets and legends in forms?
Why do forms in the admin still output in tables when triangle outputs in nice div's?

With HTML5 going to kick off more next year and the slow learners jumping more onto xhtml strict standards and the rest of us already struggling with that.

I pestered for ages this year getting CDATA for javascript I bet others did to and When I first saw it I was stoked!

You have to appreciate the little things and NOT forget them. Do the little things, they are not hard to do, offer that little but more control and ability to build custom stuff and the other stuff mentioned above and you solve BIG problems.

BC is great and I have got what I have asked for a few times for small things this year But I think the actual problems people have is getting overlooked because in many of them doing all or some of what I mentioned will actually solve them and be less implementation.

In my opinion a bit of focus asap on these small things and get them out would please a lot of your partners massively. You would keep us very sweet till some of the bigger stuff roles out.

If I can make a web app where I can have multiple editor boxes for the client to use, few more custom fields so the layout is sweet I can use those web apps as full pages instead of having to make pages and put module tags in those pages.
Do the above and I do not need to make 4 web apps for one thing, I can do it in 1.
For the client to then use this is so much simpler.
Make a tour website with lots of information and tours under groups and have a really nice layout. Try it. No less then 3/4 web apps per tour and absolute positions and a we had to add new stuff, the client could not, to complicated. Did that twice a few months ago.
I can do it in 2 now thanks to SMALL changes.
Do more and I can do it in 1.
Again I wont need modules in modules for a lot of situations.

I have a non mandatory field in a web app.
The way you have it now basically because you can not say "if this field is empty do not output this layout for it" your saying all fields are mandatory, because that is how the system works.

If I have a group of 4 custom fields for a mini gallery with a custom layout if you only enter 3 you do not want the other showing. You have to add another custom boolean field for each and then css/javascript show hide them based on that true or false.
Code in pages you do not want.

We can not get at code, we will never do so but that basic if else statment and some == != Control is again all you need for MASSIVE gains. Again this feature alone would reduce the need for more templates for example.
More templates for things is great but if I could say in my list layout in e-commerce.....

if ( {tag_tag} = "physicalproduct" ) {
this html code
}
else {
this layout code
}
And I had a few more if's for different product types (mp3 product with sample playback and physical products which of course you do not want the playback layout on).

I would not need the 4,5,6 template layouts to do the job.
In fact if you implement that it would be a pain to make all those templates to do something like this.
A basic and simple condition ability is so much simpler.

I hope this all makes sense, I am just trying to point out that you could address these issues Now and implement the things you mentioned later and Most of your partners will be happy bunnies because the reasons people want the above can actually be solved through these small improvements.

If you did the stuff I have mentioned and in tickets etc now and the stuff you talk about comes mid/late 2010 people will not be as bothered about it.

Thanks for your time.

Blog

We hear you, we really do... hang in there!

Comments

Post a Comment

Follow us on Twitter (@adobebc)

Recent Posts

Archive

Main

Sub

Product Tour

Sell BC

Pricing

Site Info