|
_BS_ wrote: Dan asked for the feedback. Sure. I know that, of course.
I'm not referring to a specific thread but there is a difference of pointing out what can help to improve ToDoList and on the other to point at GUIs that are completely different.
_BS_ wrote: TDL would long ago have taken over the world I doubt that Dan does the same thing every night, _BS_ - try to take over the world!
_BS_ wrote: I believe, however, it is quite clear where you stand on this. When I found ToDoList I tested it immediately and it didn't take me long to decide to use it (just a couple of hours). It was "love on first sight". The clear interface that gives a great distraction free overview, the edit fields, the options, the commands etc etc etc...
I've tested so many programs with hollow promises. To find ToDoList was a relief.
Dan has advanced ToDoList so much since I found it but he remained true to the way ToDoList looks. And that's what counts for me, too.
Jochen
|
|
|
|
|
Hi!
The original post "TDL is ugly?" was published by Dan, not by me.
He had an interest in this issue, and, as I am a designer, I was particularly interesting to me too.
I am the first fan of TDL. That does not prevent that one believes it is possible to make TDL improvements in visual-functional area.
There are several things I do not share of your post. But it would be long to explain.
No doubt that TDL is one of the best (if not THE best). But that is not enough.
As BS says: "If the premise weren't true, TDL would long ago have taken over the world, and it has not".
For now, I do not know if you have in mind that there are many kinds of user and not everyone uses all the tools of TDL. Make very versatile software has advantages and difficulties. If one makes a very versatile software has to find a way that different users can see what they need and easily hide what they do not need. I think this is one of the points that TDL can improve further.
Another thing that can improve (see the other post here: http://www.codeproject.com/Messages/4720836/Re-TDL-is-ugly-back-to-old-question.aspx[^] ) is that small amount of little things that would improve the TDL user experience (location of buttons, hide / unhide, drag and drop taks, etc.).
It's not just a matter of aesthetics, IMHO.
I love TDL
Armando
|
|
|
|
|
Armando TDL wrote: The original post "TDL is ugly?" was published by Dan, not by me. Sure. I know that, of course. I wasn't not referring to a specific thread of yours.
Armando TDL wrote: I am the first fan of TDL. That does not prevent that one believes it is possible to make TDL improvements in visual-functional area. Improvements. That's the point. But there are too many threads that point to other programms with a completely different interface.
When I found ToDoList I tested it immediately and it didn't take me long to decide to use it (just a couple of hours). It was "love on first sight". The clear interface that gives a great distraction free overview, the edit fields, the options, the commands etc etc etc...
I've tested so many programs with hollow promises. To find ToDoList was a relief.
Dan has advanced ToDoList so much since I found it but he remained true to the way ToDoList looks. And that's what counts for me, too.
Armando TDL wrote: If one makes a very versatile software has to find a way that different users can see what they need and easily hide what they do not need In general: yes. I agreee. My point was to make say that ToDoList shouldn't evolve from a "workhorse" to a fany looking, so called "nice application" just because some people cannot stand to see a few buttons (they do not need). We had this discussion already in the past!
Armando TDL wrote: It's not just a matter of aesthetics, IMHO. I agree, but the headline "TDL ugly" implied that this is the subject to talk about. If you are referring to functionality the question is: what features would you like to have? That's another thread.
Jochen
|
|
|
|
|
TCP_JM wrote: If you are referring to functionality the question is: what features would you like to have?
I think that is the difficult part. Functionality slips fairly easily into the conversation about the UI, and Dan even led the feedback in this direction by asking:
3. Specific suggestions for features that are more geared to users' outcomes, various use-cases that we can incorporate into workflows. Perhaps even a completely separate and optional menu structure for newcomers.
TCP_JM wrote: My point was to make say that ToDoList shouldn't evolve from a "workhorse" to a fany looking, so called "nice application" just because some people cannot stand to see a few buttons (they do not need). We had this discussion already in the past!
I totally agree TDL needs to be a work-horse. I also don't have a problem with the aesthetics. However, having only the info I need is helpful - it removes friction. Having a bit more flexibility and functionality in the interface would be nice - but is it a deal breaker? - hell no.
To me, the question of the interface revolves around the benefits and who it is going to help and attract. While the TDL UI actually has a lot of flexibility already, the most efficient way of accessing these is through keyboard shortcuts. And the vast majority of people I know are lucky if they use / know many more shortcuts than ctrl C and V (excepting the IT department of course).
If you want to attract these people, TDL would need to have a dumbed down, simpler GUI/mouse mode IMO. Assuming you wanted to attract them. But then you could argue they have plenty of other options to choose from.
|
|
|
|
|
I'm glad this brought you 'out of the woodwork'. I should try it more often
|
|
|
|
|
Hi Dan,
.dan.g. wrote: I'm glad this brought you 'out of the woodwork'. I should try it more often That's funny . Try it out!
The "woodwork" I'm in at present is the work that results from the fact that is "this time of the year", which means a lot of people are trying to do a lot of things that they could have done earlier this year in the last couple of days in this year. I'm not a protagonist in this regard but I'm not excluding myself either...
My "free time" woodwork is the manual. I've got a few questions about features and I'm sending you an email about that in the next couple of days.
Cheers,
Jochen
modified 13-Dec-13 8:46am.
|
|
|
|
|
Hi. Have a look around the 5 minute mark - they have a type of 'day view'.
|
|
|
|
|
zajchapp wrote: Have a look around the 5 minute mark - they have a type of 'day view'. Ho, ho, ho.
Your remark sounds correct, but let me say this: There is a little difference between an additional view (that fits visually to the other views and therefore doesn't change the whole look&feel of ToDoList) and some attempts to change the GUI of ToDoList. Right?
Jochen
|
|
|
|
|
TCP_JM wrote: There is a little difference between an additional view (that fits visually to the other views and therefore doesn't change the whole look&feel of ToDoList) and some attempts to change the GUI of ToDoList. Right?
Absolutely. Was a 'hey look at this' - not really anything to do with the topic of the thread.
|
|
|
|
|
|
Thx Armando, those were very useful images, although _I_ found the main interface more overwhelming that TDL
However, there are some good ideas that I will look at some more.
ps. Is there a page of other screenshots that you can point me to?
|
|
|
|
|
|
One comment I would have is that pop out pages for data entry might look good but they are really inefficient. I strongly support the TDL approach of being able to have everything on a single screen even if it does make the interface look busy.
|
|
|
|
|
Reposting Re: How to hide the task ID in print outs using a x.aspx
Apologies if this is a faux paus - seems to me responses to old threads stay deeply buried with their threads; so nobody sees the question to answer if they know.
verithin wrote: ... Anyway, I managed to amend the TodoListStyler_v1.5s.xls file that comes with TDL to my needs, except that if I use this stylesheet for printing, it always prints the task ID (which is undesired).
If I use the same stylesheet for 'Due Task Notification', it works perfectly.
After having searched for this problem, I learnt that the task ID is always printed, unless a specific 'Hide' command is used to avoid this.
Could anyone let me know this specific command line to use it in the above-said stylesheet?
Later in the thread, it is suggested to comment out the call to task id in that stylesheet.
In my case, I'm beating up SimpStyler, which has no such call to comment out.
What is the nature of the 'hide' command referred to?
Neither <span hidden> nor <span style="display:none"> is doing it. (The markup is correct / accurate in the file itself - I can put test bits within the span and those bits are correctly not displayed.)
[Was hoping that by specifically calling (and hiding) it it wouldn't come out elsewhere by itself.]
The stylesheet correctly does not display the task id when called outside of TDL - task id is only diplaying when the stylesheet is called within TDL itself. (Print preview, print, or transform.)
|
|
|
|
|
Because without the task ID, a tasklist is virtually useless, I always add it even if the user did not ask for it.
However, if they did not ask for it then I add the HIDE tag, which is referred to by verithin.
So I'm guessing that it must be possible to test for this tag...
|
|
|
|
|
"Because without the task ID, a tasklist is virtually useless, I always add it even if the user did not ask for it." - to the code, maybe. Maybe not for a user with a small enough list. They'll likely be looking by position or name. Especially if the task id column is not visible.
"However, if they did not ask for it then I add the HIDE tag, which is referred to by verithin.
So I'm guessing that it must be possible to test for this tag..."
Which is what we're asking. We haven't come across the 'hide' tag you're referring to. Not saying it's not there, merely that we don't see it / don't understand, to comprehend what you're talking about and make use of your answer.
I don't doubt it's possible to test for the tag. I've tried. It's not working for me. I'm obviously trying the wrong thing and have asked what the right thing to try is.
Could you give an example? (Bit of code?) e.g. <xsl:if test="@ID"><span hidden><xsl:select @ID></span>
doesn't do it. (Apologies for incorrect syntax, going by very poor memory.)
|
|
|
|
|
|
(1) Now I'm confused:
"I always add it even if the user did not ask for it."
"However, if they did not ask for it then I add the HIDE tag"
Huh? OH, OK ...
I guess my question is then, what do you mean by a 'HIDE tag'
(2) This is wiggy ...
Just noticed ... if I export visible columns, I get task ids. If I export all columns, I don't. Wha?
(Whatever. I'll just use all columns - it's up to the style sheet to pull the columns it wants.)
(3) I think the issue is less that the task ids come out, than it is they come out in undesirable places. e.g. On a line by themselves in some cases, in others just before the comments, with no spacing afterwards. (IIRC.)
Which is to say, not under stylesheet control / where desired / formatted to fit in with the rest of the stylesheet determined positioning.
- if they came out, instead, in brackets or something, immediately after the title, I expect this would be less of an issue. As it stands now, placement is rather in your face noticeably out of place
(4) However ...
For reasons I can't fathom, comments always come out.
I would like to explain the difference in output for task ids between all columns and not - it feels like if that can be explained, then I suspect the cause of comments always coming out will also be explained.
Dan - if you are doing something special/different for task ids, all columns or visible only, could you please confirm the same (treatment) is happening for comments too?
- otherwise, I'm at a loss as to how to stop comments from coming out. (My stylesheet puts them in, in a controlled / suitable spot, but they're coming out on their own a 2nd time too. Which is baffling.)
|
|
|
|
|
Consider the SimpStyler sample xsl.
In there it calls for the field @TITLE, and like you would expect, prints the title.
There are lots of @{fields} that aren't called for and don't come out - which is a good thing.
Nowhere does it call for the comments, yet the comments come out.
Why is that? (i.e. There's something very basic there about stylesheets that I don't understand - enlightenment would be appreciated.)
How do I stop the comments from coming out?
(I want the comments, just under my control / formatting - not auto-magically appended. e.g. If I put the comment fields in, I get the comments twice. Under my control, and not.)
[Seems there's a different approach used in most of the other stylesheets, character by character control of -everything-. e.g. programmatically outputting all the html elements as objects, with css/style properties settings. Trying to avoid that level of 'indepth' programming Granted - absolute control, but also a LOT of work.)
It's not just a matter of turning comments off - Dan has indicated the way to do batch processing is via msxsl - there is no GUI at that point, and so no checkbox to uncheck. The stylesheet has to handle it and/or not have uncontrolled text coming out by itself.
|
|
|
|
|
_BS_ wrote: Why is that? (i.e. There's something very basic there about stylesheets that I don't understand - enlightenment would be appreciated.)
Great question on something I just moved past very early on. Certain stylesheets seem to do odd stuff - like simplstyler. And I haven't yet been able to work out why.
I went to the character by character control method because of this. This seemed to do what it is supposed to.
A similar issue was raised in this post. I have checked the code, and haven't been able to find any significant difference between stylesheets that apparently use the same code by output differently (e.g. ToDoListStyler vs Z_DetailedReport). I still intend to incrementally snip out pieces of code to try to find the offending bits...
ToDoList 6.8.2 Feature Release - An effective and flexible way to keep on top of your tasks[^]
|
|
|
|
|
.
I do not (yet) have an answer, but I do have a solution.
My guess is that a transform reads the .xml from top to bottom, spitting out xsl formatted output along the way. If it sees a tag, and has an xml:template for it, it uses it.
When it doesn't, it strips any tags, and dumps out the contents.
(If it has a 'handler', it uses it. If it doesn't it uses a default handler, dump.)
So:
(1) You need an xsl:template match=COMMENTS line somewhere. (With nothing in it / between the tags - causing the content to be swallowed.)
(2) Even if you call for the comments via xsl:value-of select="COMMENTS"
I got here by starting with an absolutely blank .xsl and building it up (towards SimpStyler, could have been anything).
I figured the above out when even a blank xsl got:
GroceriesHomeTravelWorkBobJaneMaryPete
Wha? Where did that come from?
At the bottom of Introduction.tdl is:
<CATEGORY>Groceries</CATEGORY>
<CATEGORY>Home</CATEGORY>
<CATEGORY>Travel</CATEGORY>
<CATEGORY>Work</CATEGORY>
<PERSON>Bob</PERSON>
<PERSON>Jane</PERSON>
<PERSON>Mary</PERSON>
<PERSON>Pete</PERSON>
So, a bare minimum stylesheet is:
(Dan - perhaps this would be a useful bit in Resources/Stylesheets - BlankStylesheet.xsl, providing people with a zero line.)
<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:strip-space elements="*" />
<xsl:template match="TODOLIST">
<html>
<head>
<title>SAMPLE PAGE TITLE</title>
</head>
<body>
<h2>HELLO WORLD</h2>
<ul>
<xsl:apply-templates />
</ul>
</body>
</html>
</xsl:template>
<xsl:template match="TASK">
<p><xsl:value-of select="@TITLE" /></p>
<!-- <ul><xsl:value-of select="COMMENTS" /></ul> -->
</xsl:template>
<xsl:template match="COMMENTS"></xsl:template>
<xsl:template match="CUSTOMCOMMENTS"></xsl:template>
<xsl:template match="CATEGORY"></xsl:template>
<xsl:template match="CATEGORY"></xsl:template>
<xsl:template match="METADATA"></xsl:template>
</xsl:stylesheet>
Adding the CATEGORY and PERSON pairs made the unexpected output go away.
GroceriesHomeTravelWorkBobJaneMaryPete
Therefore, I assume, if you're seeing COMMENTS, an equivalent pair is missing in the stylesheet. (With @COMMENTS, this would never have been an issue.) If so, add the two lines, and get on with your day.
Comment out the @TITLE call to make it disappear too.
Uncomment the COMMENTS calls to add in comments. ONCE!
If any of my very uneducated guesses are incorrect here, I would appreciate a heads up. VERY MUCH!
.
modified 13-Dec-13 11:06am.
|
|
|
|
|
|
Got to say, some of the language leaves me a little lost as a non-programmer. As I understand it:
@COMMENTSTYPE="849cf988-79fe-418a-a40d-01fe3afcab2c" indicates rich text comment
@COMMENTSTYPE="PLAIN_TEXT" indicates simple text comment
@COMMENTSTYPE is an attribute of the TASK node, and appears whether there is a comment present or not.
COMMENTS is a sub-node of the TASK node that only appears if there is a comment present. It contains the Comment text of the task.
CUSTOMCOMMENTS is a sub-node of the TASK node that only appears if there is a comment present, and it is rich text. It contains the rich text formatting information (I think).
I have not come across CUSTOMCOMMENTSTYPE
HTMLCOMMENTS is a sub-node of the TASK node, but does not appear in the TDL file. It is generated upon the transformation of the file, from the COMMENTS and CUSTOMCOMMENTS information (I think).
Note: If you start TDL (6.7) with -g for logging, the temporary tasklists generated for the transform are saved to C:\Documents and Settings\your_user_name\Local Settings\Temp . Useful for inspection.
Note: Attributes are addressed by adding an @ in front of the name, while nodes and sub-nodes are not. For example @COMMENTSTYPE and COMMENTS.
zajchap
|
|
|
|
|
For what it is worth, all this discussion has prompted me to look into this a little more. I have come to realise why this has taken me quite a while to get my head around. The thing is, creating stylesheets actually involves knowledge and application of several languages(? - not sure if that is the right term).
- xml: the structure of the data - a tree, and the particular schema you are working with
- xsl: the commands to manipulate the XML - how to do the transformation
- xpath: the commands to navigate the xml tree - what to do the transformation on
- HTML: the display language for the output - the output of the stylesheet
- CCS: the language to apply formatting to the HTML
I made a comment about this a week or so ago, but didn't really fully put 2 and 2 together. The stylesheets pretty much all take selected data from an XML file structure and transform it into HTML for presentation purposes.
I didn't really fully realise that the stylesheet is actually creating HTML, and therefore has a lot of HTML and HTML structures in it. Seems obvious now
zajchap
|
|
|
|
|
@COMMENT -> COMMENT noted.
You left out .xsd for the schema.
These are indeed all languages.
xml is just a database. Somewhat uniquely, it is human readable. And, human mungeable - the cause of many problems. And open to much abuse for not requiring strict adherence to a dictionary. Sure, go ahead and throw that new field in, what could the harm be? As everything before and after breaks down, perhaps years later.
As languages, these are all (relatively) trivial.
Two or three things whack us:
- It is not enough to know the language, the languages use objects. And every object is different and has a learning curve. Although the language is the same everywhere, the objects used typically depend upon the particular environment in which they are used. For example, different browser interpretations of the same information.
- for each file beastie, there is something interpreting it. The editor, the character set, the dictionary, the data query, the transform, the style, the browser. Let alone the independently operating GUI. A sequence of independent programs (each with their own specs, inputs, and outputs) that have to work sufficiently well contiguously to be able to take your keystrokes and munge everything into something that hits your eyes (in a browser, typically).
- now add in different browsers, different operating systems, different spoken/written languages ...
The stylesheet is a transform (set of instructions). A black box. It takes input, chews on it, and produces output. It can produce text, html, pdf, or anything else desired.
FWIW.
|
|
|
|
|