Just when is Fall anyway?

OK, first the burning question… when is that Fall Release happening? As Peter loves to remind me, Fall just started on September 21st. So, based on that, we anticipate having a mid-Fall release, meaning the first week of November-ish. The "ish" part is included because the quality of the release is our highest priority and with software there is always some amount of unexpected. All is proceeding as expected, but I want to set your expectations appropriately and it is possible that something could change. Workgroup administrators and applications managers will be notified of the QuickBase release 7-10 days in advance.

We will have a beta version available soon. If you are interested in participating in the Beta, please enter a support request indicating your testing interests (based on what’s described here: http://quickbase.typepad.com/blog/2005/08/whats_ahead_for.html), your applications (just a general idea of what your doing with QuickBase) and your availability over the next few weeks, and we’ll get back to you with more information. One note: You will not have access to your current applications in the beta environment.

In addition, we have an internal, automated testing platform named Shadow. It "shadows" the production environment seeing every request and running that against the release candidate build. We already have many of our most complex applications testing in this environment, but we can always learn from more. If you are interested in having your application run through our Shadow environment (you won’t need to do anything, but give us permission), please also enter Support request. Shadow testing will not have any impact on your production applications. They are separate systems.

If you want to participate in both, you can just put in one request.

  • Dave H

    Glad to hear that things are progressing, thanks for the update!

    [Reply]

  • Dave H

    Glad to hear that things are progressing, thanks for the update!

    [Reply]

  • James LaCorte

    I am excited about “Enhanced Integration and Consolidation”. If it does what I am thinking, it will increase our use of QB.

    We need the ability to have applications relate to each other and copy over key info. Example a project portfolio application we have profile and status reports. In another application PM track their project, issues, risks, etc… We would like to use a shared multiple choice field from the portfolioe application to get the project name and copy over key fields as reference. This is only one example.

    [Reply]

  • James LaCorte

    I am excited about “Enhanced Integration and Consolidation”. If it does what I am thinking, it will increase our use of QB.

    We need the ability to have applications relate to each other and copy over key info. Example a project portfolio application we have profile and status reports. In another application PM track their project, issues, risks, etc… We would like to use a shared multiple choice field from the portfolioe application to get the project name and copy over key fields as reference. This is only one example.

    [Reply]

  • Tony A.

    My understanding of the new cross-app functionality is that there will be 2 ways of accessing info across applications. My understanding of these 2 options are i) a roll-up where apparently you need to identify each record to be rolled up, and ii) another type of cross-app roll-up that doesn’t require you to add each record but doesn’t update automatically; i.e., I think you need to synch the data somehow.

    I would like to create a way for my clients to see their specific data, be able to do some querying, but also not see the numerous tables in my main application. Ideally, I would like to have a simplified QB application for my clients to access the data in the main app. From what I understand the second option could work but will require that some type of manual data synchronization happen. Is my understanding correct and does this approach seem reasonable? If so, it could be an efficient way for us to provide access to our clients.

    Thanks.

    [Reply]

  • Tony A.

    My understanding of the new cross-app functionality is that there will be 2 ways of accessing info across applications. My understanding of these 2 options are i) a roll-up where apparently you need to identify each record to be rolled up, and ii) another type of cross-app roll-up that doesn’t require you to add each record but doesn’t update automatically; i.e., I think you need to synch the data somehow.

    I would like to create a way for my clients to see their specific data, be able to do some querying, but also not see the numerous tables in my main application. Ideally, I would like to have a simplified QB application for my clients to access the data in the main app. From what I understand the second option could work but will require that some type of manual data synchronization happen. Is my understanding correct and does this approach seem reasonable? If so, it could be an efficient way for us to provide access to our clients.

    Thanks.

    [Reply]

  • Dave H

    One of the major needs I see for Quickbase is a better templating engine.

    1) The templating needs to be server-side, so that it doesn’t depend on browser support
    2) There needs to be a default template providing the functionality that user’s expect of a quickbase application, so that we can extend it rather than providing a more anemic representation of the data
    3) There needs to be the ability to create a global application menu, visible from all views
    4) There needs to be the ability to display related information. e.g. If we have an employees that is self-related in order to show a management hierarchy and a department table, you should be able to do something like ‘employee.manager.department.’ to get information to use in the template. XSL simply does not provide the needed functionality, because in order to get that information you’d have to either code in a javascript that fetches that information after the page is loaded, or use horribly cludgy and poorly supported xml/xsl includes.

    Just a few ideas ;)
    -Dave

    [Reply]

  • Dave H

    One of the major needs I see for Quickbase is a better templating engine.

    1) The templating needs to be server-side, so that it doesn’t depend on browser support
    2) There needs to be a default template providing the functionality that user’s expect of a quickbase application, so that we can extend it rather than providing a more anemic representation of the data
    3) There needs to be the ability to create a global application menu, visible from all views
    4) There needs to be the ability to display related information. e.g. If we have an employees that is self-related in order to show a management hierarchy and a department table, you should be able to do something like ‘employee.manager.department.’ to get information to use in the template. XSL simply does not provide the needed functionality, because in order to get that information you’d have to either code in a javascript that fetches that information after the page is loaded, or use horribly cludgy and poorly supported xml/xsl includes.

    Just a few ideas ;)
    -Dave

    [Reply]

  • james

    ETA on beta and final release?

    [Reply]

  • james

    ETA on beta and final release?

    [Reply]