文章 "如何在"应用商店"中发布产品" - 页 15

新评论
 

我明白了，谢谢。

我想，建议我们扩大市场的功能，以更大的灵活性来解决所提出的问题是没有意义的。

 


如果库不是智能交易系统、指标或脚本，而是一个库，那么 "类型 "对库意味着什么？

 

说明中对内部锚点的引用被删除了，这很糟糕--文本可以更方便。

我正试图按照 MQL 文档的风格编写函数说明 - CSS 引用被删除，类被移除....。也许有简单的方法？也许有人能给我一点提示？

 
Y.A.K._:

说明中对内部锚点的引用被删除了，这很糟糕--文本可以更方便。

我正试图按照 MQL 文档的风格编写函数说明 - CSS 引用被删除，类被移除....。也许有简单的方法？也许有人能给我一点提示？

使用与我们网站文档中名称相同的 CSS 样式。

Css 文件可以从网站下载，样式名称可以在文档的源页面找到。

 
Renat:

使用与网站文档中相同名称的 css 样式。

你可以从网站上下载 css 文件，并在文档页面的源代码中查看样式名称。

谢谢，但样式名称没有保存。我从 css 中复制并粘贴到 span 样式中，只保存了颜色，但大体上看起来已经差不多了。完成第一个功能后就容易多了。

不过今后最好还是想点办法（可视化编辑器一般都很强大）。

 

我发现我的产品描述超过了规定的 3600 个字符的限制。 谁想出了这个愚蠢的限制？ 如果这个产品比两条移动平均线 和各种 "只要运行它，它就会自己完成所有事情 "的黑盒子还要复杂，你怎么能用这么简短的形式描述它呢？这就需要详细描述操作原理、特点、所有参数的分配以及其他细微差别。 3600 个字符是不够的。 或者我该怎么做，缩写每个单词（dr. tr. pr.）？

总的来说，这一切都太轻浮了，甚至可以说是小家子气。 Yandex 免费赠送太字节，而你却要挤占额外的文本千字节，将图片大小缩小到 640x480 以及其他限制，同时还要从该产品的销售中分一杯羹。也就是说，他们似乎应该对高质量的描述感兴趣，还是从节省匹配上获得更多利润？

更糟糕的是，系统甚至不允许在草稿中保存超出限制的描述。结果，切换到另一个标签页再回到 "描述 "时，我在几个小时内完成的所有工作都丢失了（所有内容都已经写好，格式也正确）。 总的来说，到目前为止，只有不愉快的印象。

 
meat:

我发现我的产品描述超过了规定的 3600 个字符的限制。 是谁想出这个愚蠢的限制的？ 如果这个产品比两条移动平均线和各种 "只要运行它，它就会自己完成所有事情 "的黑盒子还要复杂，你怎么能用这么简短的形式来描述它呢？它需要详细描述操作原理、特点、所有参数的分配以及其他细微差别。 3600 个符号根本装不下。 或者我该怎么做，缩写每个单词（dr. tr. pr.）


创建一份完整的文档，并在产品讨论区发布。有什么问题？
 
meat:
用户有不爱看长文的毛病。因此，给他们一大段技术性文字作为当头一棒，对产品本身并无益处。
 
marketeer:
用户有不爱看长文的毛病。因此，给他们一大段技术性文字当头棒喝，对产品本身并无好处。

我的产品不适合这样的用户，它是一个纯技术性的东西，需要对所有细微差别进行详细描述。

我意识到，有很多产品的整个描述都是 "非常酷"、"试用后一定不会后悔 "等欢快的赞叹和粉红色的鼻涕。 俗话说，产品是什么，描述就是什么。

 
Rosh:
创建完整的文档并发布在产品讨论区。有什么问题？

展示的产品应该是一套完整的产品，包括文档和其他东西。而不是涂抹在论坛讨论区的某个地方。试想一下，如果您的 MT 文档不是张贴在专门指定的地方，而是张贴在某些论坛讨论中。

有什么理由不为此单独开辟一个 "文档 "标签呢？ 或者提供一个机会，将您的 PDF 文件与文档附在一起。 这样一切就会显得文明：有一个产品，就有它的文档，而文档在 "文档 "部分，而不是像您建议的那样在 "洪水 "部分。

1...8910111213141516171819202122...54
新评论