PDMworks and DBworks??

dbworks works fine, but user interface is totally and absolutely crappy. people at mechworks are completely unable to produce any sort of pleasant user interface and they don't mind in any way emails received by users. never seen such a stupid interface since word for dos 4.0... you can't move across windows with key --not even when inserting text in text boxes...--, you never get any reasonable responce when pushing arrow keys and the main window uses the most stupid array of controls they could choose to show you your documents. the nice thing is that with every new release they change key assignments randomly. in an unpredictable way, when creating a new project the subwindows of the main window moves around and their sizes get messed. when exporting a project or subproject tree to an html file you have a relatively small tree-size limit, and this becomes quickly a problem. the other thing is it uses some levels of nested tables and there are many html tags errors in the output file. removing parts from subprojects not always works as expected and often you say bad words because of the dumb management of the main window views of projects. they didn't thing about the possibility of showing subtrees *while* building them. then, when you need/want to see a big projects/subprojects tree you may have to wait some *minutes*. probably in 2.675e+17 releases they'll fix all these things.

but user interface apart, it's a good package. powerful and working fine.

my 2 eurocents.

Pete,

I've been playing with DBWorks 2004 Beta 3 for the last week or so. Coming from a PDM\Works background (4 Years -- 30 seat install) I am biased towards PDM/Works' simpler interface. The latest version of PDM/Works (2004) has some very nice refinements.

However, I cannot see any new functionality being added to PDM|Works without it encroaching on Smarteam's (Another Dassault Product)customer base. Given the price difference between the two, my guess is the margins are a lot better with Smarteam when you consider the installation & configuration costs.

This can be seen with PDM\Works current pricing scheme which requires users to coughing up another $5K for the Advanced Server. This module basically allows access to the PDM/Works API calls.

The only rational for this type of marketing position (in my opinion)is to allow SW salesman to up sell PDM\Works power users to Smarteam.

i.e. "Given the cost of PDM\Works Advanced Server.... and the customization required to make it work..... you might as well pay a little extra to get the "out of the box" functionality of Smarteam........"

For single users DBWorks is half the price of PDM/Works and 20x more powerful. Granted the installation is more complicated (buy the adminstration manual -- it is worth its weight in Gold) and the user must know how SW works inside and out (hope you didn't fall asleep in the SW class when they were going over the SW options).

Granted it has some quirks (like any other software) but I am really beginning to like it.

My top ten reasons why I like DBWorks.

1. Simple to use.
2. Easy to maintain.
3. Automates drawing creation (filling in Title Blocks, Auto-numbering files).
4. Revision control of configurations and derived parts.
5. Generation of Project BOM's and purchasing lists.
6. Different materials in a single part file (i.e. SST, Al, CS parts with identical geometry).
7. Replaces all the third party macros/add-ins for entering custom/configuration properties.
8. Allows the use of external database fields to populate dropdown list boxes (i.e. use the MRP/ERP database to populate fields such as suppliers, order quantity, etc..)
9. Addition of phantom parts in a BOM without having to fake it by dropping an empty part.
10. Forcing mandatory fields to be filled in during saves or approval process. (i.e. lets engineers be loose with data during developement but then making sure it is added prior to being released.

The list is growing daily.

In conclusion:

There are three types of PDM/PLM systems: Workgroup, Department, & Company. As you move from Workgroup to Company the functionality increases at the same rate as the complexity of installing and running the system.

DBWorks is close to the functionality of a Company PDM\PLM with the complexity between a traditional Workgroup and Department PDM system.

It offers very good value for the money if you use it "out of the box".

Cheers,

Len K. Mar, P.Eng. President E-data Solutions

Hi Gianni,

In DBWorks 2004 the interface has been the first reason of concern and it has been rearranged and improved:

1) DBWorks runs inside SW as a model window 2) The project tree page has been redesigned to offer all the features previously offered by the lists window in a tidy, simple interface 3) Search interface has been simplified and made more appealing, letting you recall all recent complex searches with a click 4) Workflow decisions have been simplified with a new interface

There's certainly more than this, but an entire list here wouldn't make sense. You can have a preview at the address: http://62.101.95.130/mechworks/dbworks2004/html/intro.htm You can see screenshot of the interface there, new elements are described in detail. I won't discuss the 'crappiness' of the interface, go there, look and make your opinion on the subject. If you have any advice, send us an e-mail at snipped-for-privacy@mechworks.com

This brings me to another subject: you wrote "they don't mind in any way emails received by users". We have a good record of minding the users opinions and are proud of it, so the first thing I did was looking for e-mails from you through the years. No advice, no complaints, no requests, nothing. If you want us to 'mind your e-mails' please help us by sending an e-mail.

We receive e-mails of requests/advice from all over the world. Funny we don't get feedback from a guy who lives at less than an hour drive from our office.

Going back to complaints, after your message we will retest the use of keys and of tab keys in particular.

Tree rebuilding has been made quicker, but the best approach is always not to expand many projects at once (there's an option to make this task automatic). In any case we're talking of very few seconds for 100 projects, nothing like minutes. Performance is a high reason of concern for us and DBWorks is running in companies who manage very large assemblies and large projects (SIG packaging, Bosch packaging, to name two). If what you wrote was true, the would have discarded DBWorks from day 1. I wonder how many projects you have, we can webex you any time to check the performances on your system, just get in touch.

About html output, there's an applet for parents and children and that applet has a limit of 1000 elements because of limited space (ever heard of an applet as big as more then 10 times the screen height?), but there's no limit to the number of elements in the trees. The html for the table trees is a bit complex because of dynamic behaviours that mimic a tree (expand, collapse branches). If there's any tag not closed, please let us know which. Our first reason of concern was to make sure it works correctly and it's been doing it for years. If you can't get an html for an assembly, send us a zipped copy of your database and the ID of the assembly and we'll test in-depth until we get it to work as expected.

By the way, thank you for the final line.

Giorgio Malagutti MechWorks

hi giorgio. your name sounds italian :) one of my employees in the technical office is named alessandro malaguti :)

i'm glad to hear it. as i said in my past post, the user interface wasn't what we'd like to have and it was a pity because of the good engine of the program.

nice thing.

looking forward to see --and try-- it.

good choice.

i had a look at some of the screenshots and the new user interface is far better than the actual one. it seems clear and well designed: i'll let you know the real usability, but the look is appealing.

this may be due to our var, but everytime we asked why the u.i. was designed in a certaing way or if there was the possibility to change something we got the usual answer "it's impossibile" "the company can't change nothing" "we received no answer" "blahblahblah".

from my --the final user-- point of view, this has been a problem in many situations...

the most strange thing that happened --twice-- was that, without any reason, dbworks window moved outside the screen. it got focus, it received keyboard events but it didn't show in the screen. we solved deleting dbworks user settings.

i don't know how the new interface will work, talking about keyboard response, but since windows 2.0 for dos 3.30 the tab key has been used to move thru the fields of dialog boxes, the arrow keys has been used to scrool in combo boxes, drop-down list, list boxes and grids and usually users has been able to press alt+ keys to jump to the most commonly used fields of the windows. nothing of this was found in the u.i. up to dbworks 2003. i understand that having user interface localized to many languages can give some problems when assigning alt+, but done once, done forever. at least, tab and arrow keys should work as expected, that is just like any other windows software.

i'm not saying this is the best way to use keys, but this is the most common one and a user will expect all the softwares to work the same way and, possibly, to have similar interfaces.

i understand this, but since "add project to selection" doesn't always work as expected --that is, it should just add the project i choose to the previous selection--, you quite often need to rebuild the whole projects tree and then choose the project you want to work with.

or, since project management has changed heavily at least 2 times in 4 years, you may have decided to organize your projects in a certain way and you may need to change it because of the new features of today's software. then, the projects you start now will have names you decide today, but older ones can still have names with the older conventions and, while you don't reorganize them and rename most of them, looking for them in a 6 lines drop down list isn't that comfortable. then a complete project list comes useful.

another possibility is when you get a new employee, who doesn't know how you organized your projects: he/she will often need to navigate the complete project list to find what he/she looks for.

actually, a very annoying thing is the filter window behaviour. we usually choose the "filter all the tables" and "filter all database" options because of our parts and assemblies codes. should, for any reason, you filter tables when the selection focus is on the projects list, you loose the complete project list, meaning that you don't see any projects anymore. i mean any of the selected nor the unselected ones. pressing the "home" button doesn't help, because it rebuilds all the windows but the projects one. then, the only way --and it doesn't even always work...-- is to uncheck che "show only selected projects" option and select again a list of projects to work with.

maybe there is some way to fix this --wrong, imnsho-- behaviour, but my var hasn't been able to tell me how.

100 projects were born in three days when we bought the first 3 seats in 1998. in a company with 5 seats you can quickly reach thousands of projects. i can't even imagine in big companies the huge projects tree they can have.

but the disappointing thing is, probably, not the fact that rebuilding a 3.000 projects tree takes too long --talking as a programmer, you probably didn't choose the best way to display the project tree--, but the fact that while building you can do nothing else.

if my complete rebuild takes 3 minutes --and this is very next to what happens-- and i do it three times a day --for any reason i may want to do this--, i loose one hour a week, that is 60 dollars. i have only four seats, then i'm probably loosing 150 dollars per week on tree rebuildings. if i could spend those minutes working on some opened models with swx it would be far better. this is also because *i know* nobody works hard 8 hours a day, but people want to choose on their own when to take a break and *having to* do it when *dbworks* decides disappoints people working in my technical office.

sure i will, because i hope my problems are my fault: if i'm right, just changing the way we work can improve our performances. but, as i told you, our var --and we're talking about the one that is known to be the best in our area-- hasn't been able to tell us how.

i don't think i need to mention that dbworks and solidworks files are located on a file sharing server dedicated to the technical office and not on the workstations swx is running on.

no, i haven't. and it wouldn't be a good choice. a good choice would probably be keeping in memory the whole tree and having an applet as big as the window showing you only the part filling in the available space. this is often done when having big trees because of the refresh/repaint speed of controls having too many lines.

actually, i don't know where the problem can be, then. i'll try to understand it.

now, somebody could call me crazy because i'd like to have a complete project tree exported to html --and then printed--, but since the biggest monitor you can buy is enough just to show one 50th of the projects we have, being able to rearrange the tree on paper before moving the things on the computer would be pleasant.

sure. but i guess the problem is at an earlier step: if you export a

3-level project tree, you find the same error on all the 3 levels. if you export a 5-level project tree, the same html error is found on all the 5 levels of the tree and repeated on all the branches of the tree.

probably the engineer that developed the procedure writing the html code made a mistake in a recursive subprocedure. but, as i said earlier, the tree is rendered correctly by internet exploder, so it's ok for me. problems came when showing it with older mozilla for linux versions, but today we're no more interested in this.

i'll print a rather complex tree project and will mail you what i found not to be perfectly ok.

and it still does. simply, when looking the sources, there are

--were?-- some minor errors.

you're welcome. in 2 words, what really matters in a software is that it works fine and does what it's supposed to do. the second thing is the user interface, but it's secondary to the correct working of the software. of course, as soon as a software works fine, the first thing you ask for is a good user interface.

cheers.