Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||"Edit Database File" assumes database is a file|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||christian.jansen, e.matthis, frank.schoenheit, issues, marc.neumann, ocke.janssen, uwefis|
|Issue Type:||TASK||Latest Confirmation in:||---|
Description colm.smyth 2005-01-26 13:25:31 UTC
I believe this should simply be "Administer Database" or more simply "Open Database". It actually triggers the Base application which allows the user to: - edit data - edit table and query design - edit forms - work with databases that are file-based or server-based
Comment 1 e.matthis 2005-01-28 16:36:02 UTC
Liz->Colm: Can you help me find this by listing the clicks of how to get to this string? Thanks.
Comment 2 colm.smyth 2005-01-28 16:40:50 UTC
Colm -> Liz: Certainly! 1. Launch Writer 2. Select View/Data Sources menu 3. Right-click on an item (e.g. Bibliography) in the database list
Comment 4 einstienindia 2005-02-02 08:32:02 UTC
In the above patch, modified the Name to "Edit Database..." . "Administer Database" will confuse the previous customer (OOo1.x.y). Similarly "Open Database" will create confusion wrt File-> new ...... So I think removing the File is the best Name :)
Comment 5 Frank Schönheit 2005-02-02 08:58:04 UTC
- please be aware of the fact that the regular translation and documentation deadlines already passed, and we should stretch them for really important issues only. Personally, I am not sure if this one here fits into this category. - Actually, the database which is being edited is a file, in all cases. It might refer to a database which is no file (for instance on some server), but the actual .odb file is exactly this: a file. While I agree that "database file" is not the best choice of all, "database" alone is dangerous: It suggests that the thing is a "database" in, for instance, MS Access' sense, i.e. a self-contained file. This isn't the case here - and we all know that MS Access users is what we aim at with 2.0. Actually, this was the reason why we did not name this "database", since we needed to find a compromise between promising too much, and still offerring some known terms. - If we are really going to change this string, I'd prefer "database document". Unfortuately, this would also require changing the respective string in File|New, for consistency reasons. - I'm cc'ing the iTeam of the application, to collect some opinions
Comment 6 Uwe Fischer 2005-02-02 09:46:47 UTC
For me, "Edit database file" looks OK. A file is a collection of objects like contents, table definitions, queries, forms, and more. The forms in that file are Writer documents, so "Edit database document" would not be such a good name as "Edit database file". And "Edit database" is misleading, because you do not edit the database, which may be MySQL or Oracle or dBase or the Mozilla addresses, but you edit how the access to a database looks and feels inside StarOffice Base.
Comment 7 colm.smyth 2005-02-02 11:20:24 UTC
I suggest that this problem be resolved by our terminology experts. See my earlier comments for why a "database" is not a "file".
Comment 8 Frank Schönheit 2005-02-02 11:44:24 UTC
> See my earlier comments for why a "database" is not a "file" Uhm - which ones? :) I see you argueing why the item *could* be named "Open Database", but I don't see you argueing why it *could not* be named "Open Database File". > I suggest that this problem be resolved by our terminology experts Certainly. All I'm doing is presenting my point of view, and some implications of a renaming.
Comment 9 colm.smyth 2005-02-02 12:19:15 UTC
Database != file. A database has a schema, forms, and may reside on a server (in which case it almost always consists of multiple files).A database is a logical entity. A file is a physical entity. The use cases I mentioned in my initial comment are perfomred on attributes of the database design, it's content (data), and desktop-based information (forms). Users don't even want to think of documents as files, so why should they want to think of something even more abstract (like a database) as a file? A database is not a file even to a technical user, except in the rare case of the single-file database.
Comment 10 Frank Schönheit 2005-02-02 12:54:25 UTC
Yes, a database is not a file. And what we display to the user in the data source browser (what an ancient name), and what she is editing when she chooses the menu item in question, is not a database. It is also *not* really the file she is editing, since of course she *can* manipulate the server-side data definition from within our application. That's exactly the terminology problem we have, with our concept of "files without the actual data": We cannot say "database" because it implies (to a significat percentage of our target audience) that it's a self-contained database - which it isn't. We cannot say "database file" because it's too techy. We cannot say "database document" because of whatever. We cannot say "Database connection file" or "Data source file" or so because it's definately too techy. We have a conceptual problem here, and the agreement in the iTeam, when we realized and discussed this, was that "database file" is the best compromise. I'm open to re-discussing this, but we should a) involve the whole iTeam on this and b) find arguments why the problem caused by "database" is better than the problem caused by "database file". In my opinion, I didn't see the latter, so far.
Comment 11 colm.smyth 2005-02-02 13:11:50 UTC
By all means involve the I-team but I think you need to justify why a database is a "file". I just want to refer to it as a "database" which I think is not a difficult or unusual term for what is a "database"!
Comment 12 Frank Schönheit 2005-02-02 13:14:11 UTC
> Users don't even want to think of documents as files I want to question this. One really important goal for OOo Base 2.0 was exactly this: Users should be able to treat our former data sources as "files", as they can in MSO. They should be able to share there database with their friends and colleagues in the very same way as they do with text documents, spreadsheets, drawings, and so on. And this definately involves file handling - for all applications, not only Base. Thus, the goal was "make 'databases' files". In a more general context (not regarding Base only): It might be that in some theoretic, abstract sense documents are different from files. In reality, they aren't. And I claim that a high percentage of our users thinks the same way: They are opening *files*, not "document". The menu item is named "File", not "Document". The only users which have a chance of doing the move from "files" to "documents" are probably those who really work with a content management system. All others live in a world (so I claim) consisting of files.
Comment 13 Frank Schönheit 2005-02-02 13:16:49 UTC
> which I think is not a difficult or unusual term for what is a "database" Yes, but you didn't address my argument of confusing users who associate "database" with "mdb file, containing all my data". You claim "database" is better, I claim that the problems caused by using this term are too dangerous - that's why the iTeam decided on "database file" originally.
Comment 14 colm.smyth 2005-02-02 13:38:06 UTC
ColmS -> FS: To your previous comment, I think it is correct that databases should be usable as simply as files can be used, but that does not mean they are files or that they should be called files. To your most recent comment, I agree with you that most _current_ StarOffice users know that documents are files because our product is still too difficult to use for non-technical users. However the future of office productivity is to hide files fom the user (e.g. the user should be able to manage file permissions ("share my document with other users") from within StarOffice without using the system file manager/explorer). The "File" menu is a legacy of the old concept which will probably stay, but new users will forget what it really means.
Comment 15 christian.jansen 2005-02-02 14:08:49 UTC
CJ -> Liz, FS, All: I have no solution for this right now. But, however we name it should be consistent. In Writer, users have to go via View / Data Sources to browse database content. For having a consistent View-menu entry and context menu I propose to call it "Edit Data Source...". Now both fits together. But this would be a quick hack solution, only. Now to solution #2: On the wizard, which appears after selecting "New /Database" data sources are called databases. And in the "Edit" menu there is an entry which is called "Exchange Database". Selecting this, calls a dialog which also lists all registered data sources, and like in the wizard these data sources are called databases. Now compare the listed databases with the content of "View/Data Sources" - this is exactly the same content. Same things are called different. Thus, I propose to get rid of the term "Data Source" and replace it with "Database" Than we would have: - File -> New -> Database - On the wizard apears "Create new database" and "Connect to an existing database" - In the "Edit" Menu we have "Exchange Database" - Instead of "View Data Source" in the "View" menu, we would have "Browse Database" (if somebody has an better idea for this entry idea, go for it) - In the context menu of the Database tree of the currenly called "Data Sorce Browser" we would have "Edit Database..." I think for such change, correct me if I'm wrong, it is now too late. Thus I propose to move this issue to office later.
Comment 16 Frank Schönheit 2005-02-02 14:30:42 UTC
Christian, thanks for showing us that the problem is much larger than we thought ... :( In this light, "Later" might be a Good Thing (TM).
Comment 17 colm.smyth 2005-02-02 16:00:31 UTC
The problem is certainly larger than I described, but I still think it is worthwhile to have more consistent terminology in the most important ways to launch Base It is somewhat amazing that we didn't search for "Data Source" in the translation database before completing the specification.
Comment 18 e.matthis 2005-02-25 13:05:20 UTC
OK folks, this is definitely Office Later. However, we're going into Beta now so rather than have us insiders haggling, let's see what real users think. Beta feedback should be enlightening. Now some history: Originally the only term we had in OOo/SO was "database". Then we introduced new functionality that meant that the source didn't have to be a database but could also be a spreadsheet or a page off the Web, etc. The term we used became "data source" and the developers and I were happy that it was technically the correct term. (Because "data source" is the more general term and includes databases.) BUT then OOo/SO got bad press from the media and frustrated user feedback because many journalists/users did not know what "data source" meant. I was forced to change the term in key locations back to "database" so that average users would recognize the term. That is why we now have the inconsistency. Average users really don't care if the term is technically correct. They just want to get the job done and not have to think. If a word is new to them, chances are they don't say, "Oh that's something new. Let me figure it out." but rather "huh? Where's the xxx I was expecting? This software does not speak my language." If you do a Google search you'll find about 2 million results in which "database" and "data source" are used in conjunction. One example I grabbed quick is http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_18337 So, it appears that not only OOo/SO has this naming problem. It seems like a period of dual usage is necessary to educate users. Maybe by the time "office later" comes around the whole world will only speak of "data sources" and we can get rid of the term "database" :-) ---- Concerning the "Edit Database File" string, I want Beta feedback from average Joe users before I change it, so I'll have clues as to HOW to change it. I understand from the discussion that the iTeam had already come up with the string they thought was best, so I'm not going to pretend to be more in-the-know than them at this point. Let's just wait for the beta feedback rather than incur costs for an uncertain solution. Holding this issue till further notice.
Comment 19 e.matthis 2005-02-25 13:06:16 UTC
Comment 20 e.matthis 2005-07-25 14:35:06 UTC
Unfortunately not able to decide on this at present due to lack of feedback in this area. Reassigning for later consideration when more data exists. (Then if string changes are decided, must be in spec form)