[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    RE: Report format
From:       "Jonathan Bacon" <j.bacon () delta ! wlv ! ac ! uk>
Date:       2001-08-07 11:56:08
[Download RAW message or body]

Hmmm it might be a good idea to stick the reports in a DB and then the
developers could mark them as done. I could create an interface on the
website to do it. I don't know how to determine the number of problems
though in a report. The problem is that I would need to know how many
table fields to use. Unless there is a table like:

  id   app    issue    point_id    point_heading    point_references
point_details    done

Then I could create reports from the relevent app and issue entries. The
done field could be used by a developer to indicate if it is done.

This sounds much better and more functional. :-)

	Jono

-----Original Message-----
From: Adriaan de Groot [mailto:adridg@cs.kun.nl]
Sent: 07 August 2001 12:44
To: kde-usability@master.kde.org
Subject: Re: Report format


On Tue, 7 Aug 2001 kde-usability-request@master.kde.org wrote:
>    1. RE: Report Format (Jonathan Bacon)
>    2. RE: New and Revised Reports (Jonathan Bacon)
> 
> Heya JP,
> 
> I don't see the real issue witht he framework. Basically for each
point
> there is a table you copy and you fill in the information between the
> comments. What could be simpler? I think the main problems you have
had
> is with WYSIWYG editors; no offence, but it is well recognised that
> these editors often badly format HTML and mess it up. You are best
using

Well, the HTML that is there has a lot of indentation that would
*definitely* get my goat if I had to use vi to edit it. Certainly I
wouldn't use a WYSIWYG editor on something like that -- copy & pasting
invisible bits of tables is *sure* to cause problems.

On the other hand, let's take a short look at what's *in* one of these
reports. (Looking at Quanta). There's a bunch of records of problems;
each
one has 3 fields which are general text fields: descr. , references, and
solution. Sounds like a database to me.


> say I have given up on the report format or trying to get my reports
in
> the format, I am simply asking perhaps our format is a little too
table
> intensive or perhaps we should use some external script or document
> generation application (e.g., texinfo) to generate the HTML?
Currently,

Usually I'd hack together a perl script that does this. There's some
boilerplate, some variables -- like the id tags -- to be filled in, and
then there's the generation of the individual reports. Heck, even some
m4
defines would do it.

However, what about kugar or some other kde-based database + report
generating tool? Would that work? I've never used them, though.

A final possibility is writing a simple usability app based on KConfig.
I
wrote one to do colloquium talks for our local web, I suppose I could
hack
one together in an afternoon or evening.

-- 
.sig snipped

_______________________________________________
kde-usability mailing list
kde-usability@master.kde.org
http://master.kde.org/mailman/listinfo/kde-usability
_______________________________________________
kde-usability mailing list
kde-usability@master.kde.org
http://master.kde.org/mailman/listinfo/kde-usability

[prev in list] [next in list] [prev in thread] [next in thread]